Re: [Emerald] Y2K Bug with Emerald Database and SQL Server when recreating database
Josh Hillman ( (no email) )
Sun, 21 Feb 1999 14:11:58 -0500
From: Rudy Komsic <rudyk@cyberglobe.net>
>I just wanted to report a Y2K bug that I found with SQL 6.5 and the
>subaccounts saexpiredate. What I had to do after the failed Primary key
>changes was to create a whole new Emerald database, transfer all into it,
>then drop the calls table and recreate the calls table with the 5 primary
>keys (added username as primary key). Then I imported only the data from
>the calls table and after that, I deleted my Emerald database and then
>recreated it on a faster drive. Then I transferred it back but after
>transferring it, all the subaccount's saexpiredate got converted to 'Jan 1
>1900' for some odd reason :(
>
>The way I created the backup database was to generate SQL Script of the
>whole database. could it be possible that Jan 1 1900 was the default of
the
>database?
I think 1/1/1900 is what shows up in a SQL 6.5 table when no date is entered
(in an INSERT statement) to a non-nullable datetime field.
If your original saExpireDate had no dates in it and you transferred the
data into a new Emerald SubAccounts table that doesn't allow that field to
be nullable, that'd explain where the 1/1/1900 dates came from.
See:
Microsoft Year 2000 Readiness Disclosure & Resource Center
SQL Server 6.5 (English) - Win NT
http://www.microsoft.com/technet/year2k/product/user_view9796EN.htm
Josh Hillman
hillman@talstar.com
For more information about this list, including removal,
please see http://www.iea-software.com/maillist.html