Product Summary
Product: Visual C++: MFC	Version: 4.2	Category:Compliant
Language: Japanese	OS: 32-Bit Win	Release Date: 01 Jul 1996
Operational Range:	01 Jan 1980 - 18 Jan 2038
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows NT 4.0 Service Pack 4, Windows 98 Service Pack 1
Clock Dependencies:	System Clock
Last Updated:	14 Sep 1999
Product Details
Visual C++: Microsoft Foundation Classes (MFC)42.DLL and Visual C++: Microsoft Foundation Classes (MFC)42U.DLL 4.2 Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes. Note: this requires that any available and appropriate software updates or service packs have been applied. How the product runtime handles dates: There are no known problems with how MFC42 handles dates. MFC has a CTime class and a COleDateTime class. CTime can represent dates from 1/1/1970 to 1/18/2038, as it is basically under the same restrictions as the underlying C run-time library. COleDateTime uses the DATE type used for OLE Automation, and can represent dates from 1/1/100 through 12/31/9999. Two-digit shortcut handling: There is no 2-digit shortcut handling of years. Years must be completely specified. Recommended practices to develop year 2000 compliant applications: Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc. Common development errors dealing with year 2000 date issues: The most likely area for concern arises if users write their own date handling routines. Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc. Testing guidelines and recommendations: Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual C++: MFC	Version: 4.2	Category:Compliant
Language: Korean	OS: 32-Bit Win	Release Date: 01 Jul 1996
Operational Range:	01 Jan 1980 - 18 Jan 2038
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows NT 4.0 Service Pack 4, Windows 98 Service Pack 1
Clock Dependencies:	System Clock
Last Updated:	14 Sep 1999
Product Details
Visual C++: Microsoft Foundation Classes (MFC)42.DLL and Visual C++: Microsoft Foundation Classes (MFC)42U.DLL 4.2 Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes. Note: this requires that any available and appropriate software updates or service packs have been applied. How the product runtime handles dates: There are no known problems with how MFC42 handles dates. MFC has a CTime class and a COleDateTime class. CTime can represent dates from 1/1/1970 to 1/18/2038, as it is basically under the same restrictions as the underlying C run-time library. COleDateTime uses the DATE type used for OLE Automation, and can represent dates from 1/1/100 through 12/31/9999. Two-digit shortcut handling: There is no 2-digit shortcut handling of years. Years must be completely specified. Recommended practices to develop year 2000 compliant applications: Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc. Common development errors dealing with year 2000 date issues: The most likely area for concern arises if users write their own date handling routines. Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc. Testing guidelines and recommendations: Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual C++: MFC	Version: 4.2	Category:Compliant
Language: Spanish	OS: 32-Bit Win	Release Date: 01 Jul 1996
Operational Range:	01 Jan 1980 - 18 Jan 2038
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows NT 4.0 Service Pack 4, Windows 98 Service Pack 1
Clock Dependencies:	System Clock
Last Updated:	14 Sep 1999
Product Details
Visual C++: Microsoft Foundation Classes (MFC)42.DLL and Visual C++: Microsoft Foundation Classes (MFC)42U.DLL 4.2 Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes. Note: this requires that any available and appropriate software updates or service packs have been applied. How the product runtime handles dates: There are no known problems with how MFC42 handles dates. MFC has a CTime class and a COleDateTime class. CTime can represent dates from 1/1/1970 to 1/18/2038, as it is basically under the same restrictions as the underlying C run-time library. COleDateTime uses the DATE type used for OLE Automation, and can represent dates from 1/1/100 through 12/31/9999. Two-digit shortcut handling: There is no 2-digit shortcut handling of years. Years must be completely specified. Recommended practices to develop year 2000 compliant applications: Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc. Common development errors dealing with year 2000 date issues: The most likely area for concern arises if users write their own date handling routines. Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc. Testing guidelines and recommendations: Please see the "Visual C++ and the Year 2000" best practices article located at http://www.msdn.microsoft.com/visualc.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Chinese - Simplified	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Chinese - Traditional	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Czech	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: English	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: French	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: German	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Hungarian	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Italian	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Japanese	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Korean	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Polish	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Portuguese (Brazil)	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Romanian	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Russian	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	15 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 5.0	Category:Compliant*
Language: Spanish	OS: 32-Bit Win	Release Date: 01 Feb 1997
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 1 or higher.
Product Dependencies:	Visual Basic 5.0 Enterprise, Visual C++ 5.0 Enterprise, Visual InterDev 5.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	11 Sep 1999
Product Details
Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Access: 1/1/100 AD to 1/1/9999 AD Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Any value entered into a date-type grid cell is handled by OLEAUT32 and is displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 2-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server ODBC driver, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 5.0 of the Query Designer utilizes ODBC and RDO functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Chinese - Simplified	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Chinese - Traditional	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Czech	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: English	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: French	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: German	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Hungarian	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Italian	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Japanese	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Korean	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Polish	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Portuguese (Brazil)	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Romanian	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Russian	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual Database Tools	Version: 6.0	Category:Compliant*#
Language: Spanish	OS: 32-Bit Win	Release Date: 01 Jul 1998
Operational Range:	-
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	Windows NT 4 with Service Pack 3 or higher, Windows 9x, MDAC 2.0-Service Pack 2, 2.1, or higher, Visual Studio 6 Service Pack 3.
Product Dependencies:	Visual Basic 6.0 Enterprise, Visual C++ 6.0 Enterprise, Visual InterDev 6.0, Windows NT 4 Service Pack 3 or higher, Windows 9x, OLEAUT32.DLL.
Clock Dependencies:	System Clock, OLEAUT32.DLL
Last Updated:	13 Sep 1999
Product Details
Visual Database Tools Query Designer Database Designer Table Designer Czech, Hungarian, Polish, Portuguese (Brazil), Romanian, and Russian contain U.S. software. Operational Range for Data: SQL Server 6.5, 7.0: 1/1/1753 AD to 12/31/9999 AD Oracle 7.3: 1/1/4712 BC to 1/1/4712 AD Access: 1/1/100 AD to 1/1/9999 AD Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes (See Oracle Issues below.) How the product runtime handles dates: The database tools do not have a runtime environment. Two-digit shortcut handling: Dates are only used in two places in the database tools, both are in the Query Designer: The Results Pane allows the user to add new rows of data to their backend database table. Values entered into a date-type grid cell are handled by OLEAUT32 and displayed according to the "Short Date" format in the Calendar section of the Regional Settings Control Panel. A 2-digit year is thus interpreted using the same OLEAUT32 Regional Setting for 2-digit year interpretation, which is between the years 1930 and 2029 by default. Entering a 4-digit value within this range will display it as 2-digits, and a 4-digit value outside this range will be displayed as 4-digits. The Grid Pane allows the user to specify date selection criteria. Here a date value can be entered into the "Criteria" cell, which will be parsed upon exiting the cell. Using a non-SQL Server/Oracle ODBC connection, date values are converted to an explicit 4-digit format. The interpretation of 2-digit years is once again handled via the OLEAUT32 Regional Settings for 2-digit year conversion. However, when using a SQL Server connection, valid date values entered into the Grid Pane’s "Criteria" cell are not interpreted via OLEAUT32 settings. They are placed into the SQL pane unchanged. There, SQL Server will interpret a 2-digit year as the century "1900" for values greater than or equal to 50, and as "2000" for values less than 50. These are design-time issues only; the database tools do not operate in a runtime mode. Oracle Issues There is an issue regarding 2-digit year parsing when connecting to an Oracle database with a system configured for 2-digit year format. If the year entered into the Grid Pane’s Criteria cell is between 2029 and 2000 (the system default 2-digit year window for year 2000 dates) the date will be converted by OLEAUT32 into a 2-digit value when parsed into the SQL Pane. Oracle will interpret this as a year between 1929 and 1900. The work-around for this is to set your system’s Short Date format to include a 4-digit year. However, this issue is resolved by installing Visual Studio 6 Service Pack 3. Recommended practices to develop year 2000 compliant applications: It is highly recommended that the user switch the Short Date format for year in Regional Settings Control Panel to one with 4-digits, (i.e. "M/d/yyyy") to reduce confusion when working with 2-digit years. Additionally, it is good practice to use a 4-digit year whenever working with dates. When working against a SQL Server database, it is advisable to set your Regional Settings Control Panel 2-digit year interpretation to mirror that of your server. By default, this is "1950" and "2049" respectively. Common development errors dealing with year 2000 date issues: When working against a SQL Server database on a system with the default 2-digit year in the Short Date format and "1930 to 2029" 2-digit year interpretation, a user could enter a date value into the Results Pane between the years 30 and 49. (This will be stored as the year 1930 to 1949 on the backend.) Upon performing a SELECT statement, such as "SELECT * FROM <table> WHERE <datecolumn> > ‘1/1/35’", only the year 2035 records and higher will be displayed. In this case, it is best to follow the recommended practices mentioned above. Testing guidelines and recommendations: Version 6.0 of the Query Designer utilizes ADO, OLEDB, and ODBC functionality to administer user-edits in the Results Pane. Since the Query Designer is designed to work with any ODBC data source, including non-Microsoft drivers, it is advised that customers first test 4-digit date entry on sample databases to verify that dates are handled appropriately. While Microsoft has ensured that their databases and connection mechanisms are year 2000 compliant, it is possible to use the Query Designer with non-Microsoft databases and connection mechanisms.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: Chinese - Simplified	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: Chinese - Traditional	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: Czech	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: English	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: English	OS: Mac	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: French	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: German	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: Italian	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.

Product Summary
Product: Visual FoxPro	Version: 3.0b	Category:Compliant
Language: Polish	OS: 16-Bit Win	Release Date: 01 Jan 1995
Operational Range:	01 Jan 100 - 31 Dec 9999
Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement?	Yes
Prerequisites:	None
Product Dependencies:	Windows 3.1, 3.11, Windows 95, Windows 98, Windows NT 4.0 Service Pack 4, Windows NT 3.51 Service Pack 5, SQL Server 6.5 Service Pack 5, Macintosh, Power Macintosh
Clock Dependencies:	: System Clock, (OLE) Automation Libraries
Last Updated:	13 Sep 1999
Product Details
This report applies to: Professional and Standard editions. Can applications be built with this tool that adhere to the Microsoft Year 2000 Compliance Statement? Yes, if during design time 4-digit years are specified in date constants, and at run time one of the following actions is taken: 4-digit years are used for data entry. The developer writes resolution routines where appropriate to ensure that dates entered with 2-digit years are assigned to the desired century before being stored in tables. How the product runtime handles dates: Dates in variables and calculations are represented as 8-byte numeric values representing the number of days since some fixed date. In tables, date types use 8 bytes per field per record on disk and are stored internally as numeric values. This size is not affected by the settings of SET CENTURY or input masks on textboxes for data entry. This provides for full, unambiguous dates being stored independent of application logic. Two-digit shortcut handling: Dates with 2-digit years are assumed to be in the 1900s. Even if Century is set to On, entering a 2-digit shortcut for a year will cause the date to be assumed to be in the 1900s. Recommended practices to develop year 2000 compliant applications: Set Century On This feature of the product causes FoxPro to display dates with 4-digit years during data entry and display. The product default is Set Century Off. In the Off setting, it can be impossible to enter 4-digit dates and 2-digit dates are assumed to be in the 1900s. Note: Regardless of how Century is set, users can enter dates with 2-digit years. These dates will be assumed to be in the 1900s. Use the Century Property of Controls on Forms If the Century Property of a control is set to 1 – On, the century portion of a date is displayed in the control. This property overrides the current setting of SET CENTURY. The default for the Century property in Visual FoxPro 3.0 is 2 – Off. Write Date Resolution Routines to Interpret Dates with 2-digit Years If users will be entering dates with 2-digit years, developers can write date resolution routines to assign those dates to the desired century for the particular application. For instance, if dates with a year less than 75 are intended to be in the 2000s, the following code can be used in the Valid event of a control on a form to automatically adjust the century portion of entered dates. Local ldGetDate, lcMonth, lcDay, lcYear ldGetDate = THIS.Value IF YEAR(ldGetDate) < 1975 lcMonth = STR(MONTH(ldGetDate)) lcDay = STR(DAY(ldGetDate)) lcYear = STR(YEAR(ldGetDate)+100) ldGetDate = CTOD(lcMonth+"/"+lcDay+"/"+lcYear) THIS.Value = ldGetDate ENDIF If the ControlSource property is bound to a field (which happens when a field is dragged from the data environment onto the form), the field is automatically updated (with the desired date) when the Value property changes. If the control is not bound directly to a field, you may need to add additional code such as: REPLACE table.datefield WITH THIS.Value It Is Recommended that LUPDATE() Not Be Used LUPDATE() returns the date that a table was last updated. This date is read directly from the .dbf table header. However, because only two digits of the year are stored in the table header, the date the table was last updated is assumed to be in the 1900s. Use the FDATE() function instead. A developer who wishes to use LUPDATE() must write a rollover routine to assign the 2-digit year it returns to the appropriate century. Use 4-digit Years in Date Constants Date constants of the form {mm/dd/yy} are valid. However, they are interpreted to be in the 1900s. The recommended approach is to specify 4-digit years, e.g. {mm/dd/yyyy}. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Common development errors dealing with year 2000 date issues: Developers should take care to validate data entered as dates in addition to resolving ambiguous 2-digit year entries. Although Visual FoxPro provides language and tools to help developers plan for year 2000 compliance, ultimately it is the responsibility of the application (and therefore the developer) to validate data before it is stored permanently in tables. For example, if a user entering warranty expiration dates for new computers enters 04/01/1902, the application should contain logic to reject this date, even though the date exists and is year 2000 compliant. Even if SET CENTURY ON is used and dates are displayed with 4-digit years, users can enter dates with 2-digit years. The date will be assumed to be in the 1900s. If users will be entering dates with 2-digit years, write a resolution routine, as shown above, to assign those dates to the desired century for the particular application. Using dates with 2-digit years in code can lead to unexpected results. This should be avoided. Please refer to the white paper, "Year 2000 Date Support in FoxPro" Testing guidelines and recommendations: Review the application and check the forms (screens) and reports for formatting and other issues related to dates. Investigate the following areas of the product: Index tag expressions Property settings, such as in forms, classes, reports, and databases Report, label, and menu expressions Constants used in #Include files Investigate the code directly, searching for potential issues. Users can use the Visual FoxPro Filer utility to search for specific strings in the source files, such as "CTOD(", that may cause problems. Test the application under an actual year 2000 situation by setting the Windows or Macintosh system to a date in the 2000s.

Legend of Symbols:
*	The product is compliant. User action is recommended, which may include loading a software update or assessing shared technology.
#	The product is compliant with an acceptable deviation from Microsoft's standard of compliance. An acceptable deviation does not affect the core functionality, data integrity, stability or reliability of the product.
+	The product is compliant . Software updates are pending. Future maintenance actions will be recommended shortly.
Note: Compliance ratings given for each product assume that all recommended actions have been taken.