TIMESTAMP confusion
am 06.01.2005 14:32:02 von Jan Eden
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=
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
--=20
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 @m.gmane.org
Re: TIMESTAMP confusion
am 06.01.2005 15:01:59 von Jan Eden
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.
>
--=20
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 @m.gmane.org
Re: TIMESTAMP confusion
am 06.01.2005 15:25:06 von Rudy Lippan
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@m .gmane.org