Hi,

I maintain a database locally which is queried via a Perl script to generat=
e my website. Now there is one field of the TIMESTAMP type which should ref=
lect the respective page's last modification date. This works fine when the=
database is queried locally.

But when I dump the database (using mysqldump), transfer it to my webserver=
and import the dump into the database on the server, some pages carry the =
correct timestamp, while others have the timestamp of the import.

Why is that? The tables are all dropped and recreated prior to inserting th=
e data. Now I could understand if all the pages get a new timestamp (i.e. i=
f the current value is not honored at all), but some pages are not affected=
=2E

Those pages still carry the timestamp from the time when I initially added =
the TIMESTAMP field to my database. Why should this timestamp be more stick=
y than others?

Thanks,

Jan
--
How many Microsoft engineers does it take to screw in a lightbulb? None. Th=
ey just redefine "dark" as the new standard.

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules [at] m.gmane.org

Hi,

an update to my question: 219 of 2500 records on the server carry the impor=
t timestamp, while in the local database, only 65 records where modified an=
d carry a timestamp different from 20041226131319.

I am completely confused.

- Jan

Jan Eden wrote on 06.01.2005:

>Hi,
>
>I maintain a database locally which is queried via a Perl script to
>generate my website. Now there is one field of the TIMESTAMP type
>which should reflect the respective page's last modification date.
>This works fine when the database is queried locally.
>
>But when I dump the database (using mysqldump), transfer it to my
>webserver and import the dump into the database on the server, some
>pages carry the correct timestamp, while others have the timestamp
>of the import.
>
>Why is that? The tables are all dropped and recreated prior to
>inserting the data. Now I could understand if all the pages get a
>new timestamp (i.e. if the current value is not honored at all), but
>some pages are not affected.
>
>Those pages still carry the timestamp from the time when I initially
>added the TIMESTAMP field to my database. Why should this timestamp
>be more sticky than others?
>
>Thanks,
>
>Jan -- How many Microsoft engineers does it take to screw in a
>lightbulb? None. They just redefine "dark" as the new standard.
>
--
These are my principles and if you don't like them... well, I have others. =
- Groucho Marx

--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=3Dgcdmp-msql-mysql-modules [at] m.gmane.org

On Thu, 6 Jan 2005, Jan Eden wrote:

> Hi,
>

Hi

> >I maintain a database locally which is queried via a Perl script to
> >generate my website. Now there is one field of the TIMESTAMP type
> >which should reflect the respective page's last modification date.
> >This works fine when the database is queried locally.
> >
> >But when I dump the database (using mysqldump), transfer it to my
> >webserver and import the dump into the database on the server, some
> >pages carry the correct timestamp, while others have the timestamp
> >of the import.


Your best bet would be to ask this on the mysql general list.


-r


--
MySQL Perl Mailing List
For list archives: http://lists.mysql.com/perl
To unsubscribe: http://lists.mysql.com/perl?unsub=gcdmp-msql-mysql-modules [at] m .gmane.org