Is Microsoft SQL Server Y2K compliant?

A. A. It is now 2000, so you should know by now! :-)

That depends on what you mean by "compliant". If you mean the base SQL kernel functionality works as you would expect then yes, as long as you are using "proper" datetime formats then all versions of SQL Server perform correctly - if you are holding dates in char/numeric format, then it totally depends on how you are processing them, it is not an Microsoft SQL Server issue. 

SQL Server does date-windowing for two digit dates. If you specify only the last two digits of the year, values less than 50 are interpreted as 20yy, and values greater than or equal to 50 are interpreted as 19yy. For example, if you specify 3, the result is 2003. If you specify 82, the result is 1982. You must type the century when the day is omitted or when you need a century other than the default. (In SQL 7.0 you can modify the cut-off date for the windowing function).

However, if you mean the whole of the Microsoft SQL Server product set including all the gui tools, then there are a few non-showstopper problems that have been found. These are all documented at www.microsoft.com/y2k along with MS's stance and technical info on Y2K issues for all their products. The SQL 6.5 Y2K fix titles are also copied at the bottom of this note.

These problems have been found, fixed and tested in SQL 6.5 and are in Service Pack 5a - which is downloadable from support.microsoft.com.

SQL 7.0 is Y2K compliant.

SQL 1.x, 4.x and 6.0 are NOT being tested or certified by MS. They are unlikely to have any other problems than those found in the 6.5 product though, so if you can live with those (and most people can), then they should be ok. I know of no Y2K issues that companies have found with their existing 4.x and 6.x systems that can be attributed to SQL Server.

You can check MS's website for any more Y2K info on them, but all it says is that the products are legacy and have not been tested/certified.

Vendor's certification should only be one part of Y2K testing anyway - the most important part is that YOU test your clients, servers, apps, databases, networks etc. in your production environment.

------------------

SQL 6.5 Y2K bug numbers and titles

17458 Year 2000 Problem with Expiredate
17937 Y2000, ExpireDate is not set correctly when year of 2000 used in DUMP DATABASE
17947 RETAINDAYS: expired dump media can not be overwritten if current year is >= 2000
17948 Dump db with RETAINDAYS during Y2000-9, EXPIREDATE will be set to NULL
17997 Y2000: dump device dumped with expiredate set to >=2000 can be override with init
17661 Task Manager UI: one time task datetime spin box doesn't pick up 2/29/2000
18153 Web Assistant: Cannot use Year as 00 on Scheduling
18170 Invalid Y2K dates are accepted with no error by sp_addtask
18180 Invalid Y2K dates are accepted with no error by sp_purgehistory and sp_updatealert