Product Entry Guide Detail
------------------------
Microsoft Year 2000 Resource Center
Money 1.x (English)
| - | ||||||||||||||
| none | ||||||||||||||
| Windows 3.0 or later | ||||||||||||||
| Operating System Clock | ||||||||||||||
| 14 Aug 1999 | ||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – December 31, 2075, butJanuary 1, 1993 – December 31, 2075 for certain online banking services. How the product handles dates: Money version 1.0 accepts from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 1.0 handles 4-digits dates in the following manner:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. In some versions, QIF uses an apostrophe to denote dates in the 2000s. For example: 1/31’01 indicates January 31, 2001. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2.x (English)
| - | ||||||||||||||
| none | ||||||||||||||
| Windows 3.0 or later | ||||||||||||||
| Operating system clock | ||||||||||||||
| 14 Aug 1999 | ||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – December 31, 2075, butJanuary 1, 1993 – December 31, 2075 for certain online banking services How the product handles dates: Money version 2.0 accepts dates from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 2.0 handles 4-digits dates in the following manner:
Money version 2.0 handles 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047) If YY 48-99, it is considered 19xx (1948-1999) Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. In some versions, QIF uses an apostrophe to denote dates in the 2000s. For example: 1/31’01 indicates January 31, 2001. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (Canadian English)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (English)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (English Australian)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (English British)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (French)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (German)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (Italian)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 2000 (8.x) (Japanese)
| - | ||||||||||||||||||||||
| None | ||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 Service Pack 4 or later | ||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||
| 28 Sep 1999 | ||||||||||||||||||||||
|
Description of how the product accepts dates:
Money 2000 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30th, 1899 A.D. The fractional portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no fractional part. For example, January 1st, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX and OFC Money transmits date information to (and receives from) OFX and OFC using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00 it is considered 20__ __ If YY < 93, it is considered 20__ (e.g., 2092) If YY >= 93, it is considered 19__ (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092. ANSER-SPC Money transmits date information to (and receives from) ANSER-SPC without year information. When Money receives date information without year, Money uses a heuristic rule and treats either as current year or as previous year. If the day in the downloaded statements is in the future, Money assumes that the date is from last year. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Y2K compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01 ). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. Dates in the apostrophe format will be interpreted with the same heuristic as other valid QIF date formats. Users must use the Windows date format of MM/dd/YY format when they import and export QIF files using US Money 2000. This mm/dd/yy system date format is required when importing and exporting QIF according to Intuit’s Quicken QIF Y2K statement. Presented below is a table describing how Money interprets QIF data ranges: US Money2000:
* These date ranges will change as Today’s date changes according to the heuristic Money uses.
| ||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 3.x (English)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 3.1 or later | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 14 Aug 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but1/1/1993 - 12/31/2075 for certain online banking services. How the product accepts dates: Money 3.0 accepts dates from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 3.0 accepts 4-digits dates in the following manner:
Money version 3.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999). Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 3.0 was released, it did not support the apostrophe format in QIF. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 3.x (English Australian)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 3.1 or later | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but1/1/1993 - 12/31/2075 for certain online banking services. How the product accepts dates: Money 3.0 accepts dates from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 3.0 accepts 4-digits dates in the following manner:
Money version 3.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999). Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 3.0 was released, it did not support the apostrophe format in QIF. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 3.x (English British)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 3.1 or later | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but1/1/1993 - 12/31/2075 for certain online banking services. How the product accepts dates: Money 3.0 accepts dates from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 3.0 accepts 4-digits dates in the following manner:
Money version 3.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999). Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 3.0 was released, it did not support the apostrophe format in QIF. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 3.x (French)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 3.1 or later | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but1/1/1993 - 12/31/2075 for certain online banking services. How the product accepts dates: Money 3.0 accepts dates from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 3.0 accepts 4-digits dates in the following manner:
Money version 3.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999). Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 3.0 was released, it did not support the apostrophe format in QIF. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 3.x (German)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 3.1 or later | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but1/1/1993 - 12/31/2075 for certain online banking services. How the product accepts dates: Money 3.0 accepts dates from 1/1/1948 through 12/31/2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 3.0 accepts 4-digits dates in the following manner:
Money version 3.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999). Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 3.0 was released, it did not support the apostrophe format in QIF. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 4.x (Canadian French)
| - | ||||||||||||||||||
| None. | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later. | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038. | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking Services How the product accepts dates: Money version 4.0 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 4.0 accepts 4-digits dates in the following manner:
Money version 4.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 4.0 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 4.x (English)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking Services How the product accepts dates: Money version 4.0 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 4.0 accepts 4-digits dates in the following manner:
Money version 4.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 4.0 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 4.x (French)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking Services How the product accepts dates: Money version 4.0 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 4.0 accepts 4-digits dates in the following manner:
Money version 4.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 4.0 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 4.x (German)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking Services How the product accepts dates: Money version 4.0 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 4.0 accepts 4-digits dates in the following manner:
Money version 4.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 4.0 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 4.x (Portuguese (Brazil))
| - | ||||||||||||||||||
| None. | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later. | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038. | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking Services How the product accepts dates: Money version 4.0 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 4.0 accepts 4-digits dates in the following manner:
Money version 4.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 4.0 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 4.x (Spanish)
| - | ||||||||||||||||||
| None. | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later. | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038. | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally 1/1/1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking Services How the product accepts dates: Money version 4.0 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16-bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money version 4.0 accepts 4-digits dates in the following manner:
Money version 4.0 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075. Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a two-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best two-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31’01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money v. 4.0 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (Canadian French)
| - | ||||||||||||||||||
| None. | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later. | ||||||||||||||||||
| Operating system clock is not advanced beyond 2038. | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (English)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating System Clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (English British)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating System Clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (French)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating System Clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (German)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating System Clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (Portuguese (Brazil))
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating System Clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 5.x (Spanish)
| - | ||||||||||||||||||
| none | ||||||||||||||||||
| Windows 95, or Windows NT 3.51 or later | ||||||||||||||||||
| Operating System Clock is not advanced beyond 2038 | ||||||||||||||||||
| 15 Aug 1999 | ||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1948 – 12/31/2075 but,1/1/1993 - 12/31/2075 for certain online banking services. Description of how the product accepts dates: Money 97 accepts dates from January 1, 1948 through December 31, 2075. It uses a field oriented date structure with 16 bits to represent dates:
These date values are zero-based, which means to represent all possible days in a month, 31 days, and starting with 0, you need 0-30. 5 bits are needed to represent 0-30 days. To represent all possible months in a year, 12 months, and starting with 0, you need 0-11. 4 bits are needed to represent 0-11 months. This means there are 7 bits left out of the 16 bit structure for years. 7 bits can represent a maximum of 127 years. Therefore, starting in 1948, the maximum range is 1948 + 127 = 2075.
Money 97 accepts 4-digits dates in the following manner:
Money 97 accepts 2-digit dates in the following manner: If YY is 00-47, it is considered 20xx (2000-2047). If YY is 48-99, it is considered 19xx (1948-1999).
OFC and Visa: Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree/ISC/NPC: Checkfree/ISC/NPC’s specification specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years (YY) during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2075.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money97 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (Canadian French)
| - | ||||||||||||||||||||
| None | ||||||||||||||||||||
| Windows 95, or Windows NT 4 (no specific Service Pack is required, though Service Pack 3 is recommended) | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200 butJanuary 1, 1993 – December 31, 2092 for certain online banking Services How the product accepts dates:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money98 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (English)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 95, or Windows NT 4 (no specific Service Pack is required, though Service Pack 3 is recommended) | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200 butJanuary 1, 1993 – December 31, 2092 for certain online banking Services How the product accepts dates:
Money 98 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit.
OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
International (BTX/MTL) Money operates with two locale specific online drivers in Germany (BTX) and France (MTL). MTL uses YYYYMMDD format. BTX uses DD.MM.YYYY format.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money98 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (French)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 95, or Windows NT 4 (no specific Service Pack is required, though Service Pack 3 is recommended) | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200 butJanuary 1, 1993 – December 31, 2092 for certain online banking Services How the product accepts dates:
Money 98 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit.
OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
International (BTX/MTL) Money operates with two locale specific online drivers in Germany (BTX) and France (MTL). MTL uses YYYYMMDD format. BTX uses DD.MM.YYYY format.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money98 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (German)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 95, or Windows NT 4 (no specific Service Pack is required, though Service Pack 3 is recommended) | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200 butJanuary 1, 1993 – December 31, 2092 for certain online banking Services How the product accepts dates:
Money 98 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit.
OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
International (BTX/MTL) Money operates with two locale specific online drivers in Germany (BTX) and France (MTL). MTL uses YYYYMMDD format. BTX uses DD.MM.YYYY format.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money98 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (Italian)
| - | ||||||||||||||||||||
| none | ||||||||||||||||||||
| Windows 95, or Windows NT 4 (no specific Service Pack is required, though Service Pack 3 is recommended) | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200 butJanuary 1, 1993 – December 31, 2092 for certain online banking Services How the product accepts dates:
Money 98 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit.
OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
International (BTX/MTL) Money operates with two locale specific online drivers in Germany (BTX) and France (MTL). MTL uses YYYYMMDD format. BTX uses DD.MM.YYYY format.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money98 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (Japanese)
| 01 Jan 1900 - 31 Dec 2200 | |||
| None | |||
| Windows 9x Japanese language version, or Windows NT 4.0 SP4 or later | |||
| Operating system clock is not advanced beyond 2038 | |||
| 23 Jun 1999 | |||
| |||
| 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. | |
Microsoft Year 2000 Resource Center
Money 98 (Portuguese (Brazil))
| - | ||||||||||||||||||||
| None | ||||||||||||||||||||
| Windows 95, or Windows NT 4 (no specific Service Pack is required, though Service Pack 3 is recommended) | ||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200 butJanuary 1, 1993 – December 31, 2092 for certain online banking Services How the product accepts dates:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The rules of this heuristic are listed in the table below. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. When Money98 was released, this latter interpretation of the apostrophe format was standard. Presented below is a table describing how Money interprets QIF data ranges:
| ||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (Canadian French)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Money 99 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (English)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 13 Jul 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Money 99 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
The software update is available at Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # 7.00.14.2324, dated 3/24/99 2:18 pm, 495,616 bytes. This file will display as version 7.00.2324 in Windows 98 Explorer.This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (English Australian)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (English British)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (French)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Money 99 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (German)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Money 99 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (Italian)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Money 99 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (Latin America)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (Portuguese (Brazil))
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money 99 (Spanish)
| - | ||||||||||||||||||||||||||||||||||||||
| For issue #4 only: Download mnyutil.dll update (via SmartConnect or PSS) | ||||||||||||||||||||||||||||||||||||||
| Windows 95 or later; Windows NT 4.0 or later | ||||||||||||||||||||||||||||||||||||||
| Operating system clock is not advanced beyond 2038 | ||||||||||||||||||||||||||||||||||||||
| 08 Apr 1999 | ||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Generally January 1, 1900 – December 31, 2200.January 1, 1993 – December 31, 2092 for certain online banking services How the product accepts dates:
Money 99 uses the OLE Automation "DATE" data type. This is represented as a double (8-byte floating point) value. The whole-number portion represents the number of days since Dec 30, 1899 A.D. The decimal portion (which Money does not use very often) represents the fraction of a day to indicate a time (e.g., 0.25=6:00am, 0.5=noon, etc.). Dates that have no time representation are stored with no decimal part. For example, January 1, 1900 would be represented as the number 2.0.
Users can enter dates in Money as a 2-digit representation (e.g., 99, 00, 01) or a 4-digit representation (e.g., 1999, 2000, 2001). Example: in the check register, the user can enter the date 1/2/00. This date is recognized as 1/2/2000. The logic that Money uses for converting 2-digit years into the actual year varies depending on what Date data entry field is in question. Money generally uses a heuristic that compares the 2-digit year that has been entered to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. Dates are displayed in Microsoft Money consistent with the Windows date format setting. Years can be displayed as either 2 or 4-digit. OFX, OFC, Visa. Money transmits date information to (and receives from) OFX, OFC and VISA using a 4-digit format (YYYYMMDD) within the operational date range for the Money product.
Checkfree: The Checkfree/ISC/NPC 4.2 specification (dated 1/23/1996) specifies the data format for communications with Checkfree. Checkfree uses six numeric digits to represent dates as YYMMDD. Money and Checkfree exchange and translate 2-digit years during Online Banking connections using the following algorithm: If YY = 00, it is considered 2000 If YY < 93, it is considered 20xx (e.g., 2092) If YY >= 93, it is considered 19xx (e.g., 1993) Applying this formula, the operational date range for Money in connection with online bill payment services with Checkfree is 1/1/1993 to 12/31/2092.
Microsoft Money supports the QIF data transfer protocol developed by Intuit. Most versions of QIF have represented dates using a 2-digit year format. While the data stored in Money is Year 2000 compliant, Money needs to use a heuristic to determine the best 2-digit date to use when importing to or exporting from the QIF format. The heuristic compares the 2-digit year that is being imported to the current year. If the Year+1900 is more than 33 years in the past, then Money assumes that the date is in the future and uses Year+2000. In some versions, QIF uses an apostrophe to denote specific date ranges (for example 1/31'01). In Quicken 98, it is used to indicate the years from 1900 – 1949 and 2050 – 2099. In versions prior to Quicken 98, in Quicken 99, and in Money v. 4.0 and up, an apostrophe is used to indicate the years from 2000 – 2099. It is not possible to determine which range a QIF file is using and Money currently imports these dates as blank. An available file update fixes an issue wherein transactions with a date in the apostrophe format are imported into Money99 with a blank date (since the format could mean two different date ranges as described above). Dates in the apostrophe format will now be interpreted with the same heuristic as other valid QIF date formats. The file that needs to be updated for US Money99 is mnyutil.dll version # This file is automatically updated for users who use the Update Internet Information feature in Money 99 and also available from Microsoft PSS. Presented below is a table describing how Money interprets QIF data ranges (with the mnyutil.dll update): US Money99 Basic and Financial Suite:
US Money99 P&B:
* These date ranges will change as Today’s date changes according to the heuristic Money uses. | ||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
Money Central RTW 08/06/1999 (English)
| 01 Jan 1931 - 30 Dec 2030 | ||
| None | ||
| Netscape 3.x or greater (for Windows and the Macintosh); Microsoft Internet Explorer 3.02 and greater (for Windows and Macintosh); WebTV. | ||
| None | ||
| 06 Oct 1999 | ||
Money Central can be found at: http://moneycentral.msn.com/home.asp How the product handles dates: The portfolio manager, finder, and charting controls store dates in text locally as 4-digit years. When roaming portfolios are turned on for the Portfolio Manager, the date field entries are stored in a standard date field in Microsoft SQL Server 7.0. The portfolio manager also communicates with certified Brokerage OFX Servers. For these OFX servers to meet certification standards, they must transmit their date fields in 4-digit year format. The MoneyCentral Quote Server and News Server store dates as 4-digit years as well. Two-digit shortcut handling: MoneyCentral honors the date settings in the control panel. If the user chooses to display their “Short Date” or “Long Date” format as 2-digit years, MoneyCentral will display the formatting as 2-digit year format for the display and default entry mechanisms in our ActiveX Portfolio Manager, Charting, and Finder Controls. Although MoneyCentral can display dates as 2-digit years (depending upon default system date settings), MoneyCentral will store data as 4-digit years to resolve ambiguity. When the user chooses to change the custom date range in the charting tool in the stock and fund research area, by default MoneyCentral interprets 2-digit values from 00 to 30 as the years 2000 to 2030 while 31 to 99 are recognized as the years 1931 to 1999. When the user chooses to add a date field as a criteria in the investment finder, by default MoneyCentral interprets 2-digit values from 00 to 30 as the years 2000 to 2030 while 31 to 99 are recognized as the years 1931 to 1999. When the user chooses to add a new or modify an existing transaction of any type to the ActiveX Portfolio Manager, by default MoneyCentral 2-digit values from 00 to 30 as the years 2000 to 2030 while 31 to 99 are recognized as the years 1931 to 1999 for the date field in these transactions. | ||
| 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. | |
Microsoft Year 2000 Resource Center
Monster Truck Madness 2.0 (English)
| - | ||
| None | ||
| None | ||
| None | ||
| 11 Aug 1999 | ||
|
How the product handles dates: None Two-digit shortcut handling: Not Applicable What issues are there?: None Recommendations to meet compliance: None Common date usage errors: None Testing guidelines and recommendations: None | ||
| 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. | |
Microsoft Year 2000 Resource Center
Monster Truck Madness 2.0 (French)
| - | ||
| None | ||
| None | ||
| None | ||
| 11 Aug 1999 | ||
|
How the product handles dates: None Two-digit shortcut handling: Not Applicable What issues are there?: None Recommendations to meet compliance: None Common date usage errors: None Testing guidelines and recommendations: None | ||
| 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. | |
Microsoft Year 2000 Resource Center
Monster Truck Madness 2.0 (German)
| - | ||
| None | ||
| None | ||
| None | ||
| 11 Aug 1999 | ||
|
How the product handles dates: None Two-digit shortcut handling: Not Applicable What issues are there?: None Recommendations to meet compliance: None Common date usage errors: None Testing guidelines and recommendations: None | ||
| 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. | |
Microsoft Year 2000 Resource Center
Monster Truck Madness 2.0 (Japanese)
| - | ||
| None | ||
| None | ||
| None | ||
| 11 Aug 1999 | ||
|
How the product handles dates: None Two-digit shortcut handling: Not Applicable What issues are there?: None Recommendations to meet compliance: None Common date usage errors: None Testing guidelines and recommendations: None | ||
| 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. | |
Microsoft Year 2000 Resource Center
Monster Truck Madness 2.0 (Portuguese (Brazil))
| - | ||
| None | ||
| None | ||
| None | ||
| 11 Aug 1999 | ||
|
How the product handles dates: None Two-digit shortcut handling: Not Applicable What issues are there?: None Recommendations to meet compliance: None Common date usage errors: None Testing guidelines and recommendations: None | ||
| 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. | |
Microsoft Year 2000 Resource Center
Monster Truck Madness 2.0 (Spanish)
| - | ||
| None | ||
| None | ||
| None | ||
| 11 Aug 1999 | ||
|
How the product handles dates: None Two-digit shortcut handling: Not Applicable What issues are there?: None Recommendations to meet compliance: None Common date usage errors: None Testing guidelines and recommendations: None | ||
| 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. | |
Microsoft Year 2000 Resource Center
Motocross Madness 1.0 (English)
| - | ||
| none | ||
| none | ||
| none | ||
| 10 Jun 1999 | ||
|
How the product handles dates: There are no date inputting methods; dates are not utilized. Two-digit shortcut handling: Does not use 2-digit shortcuts. | ||
| 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. | |
Microsoft Year 2000 Resource Center
Motocross Madness 1.0 (French)
| - | ||
| none | ||
| none | ||
| none | ||
| 01 Jun 1999 | ||
|
How the product handles dates: There are no date inputting methods; dates are not utilized. Two-digit shortcut handling: Does not use 2-digit shortcuts. | ||
| 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. | |
Microsoft Year 2000 Resource Center
Motocross Madness 1.0 (German)
| - | ||
| none | ||
| none | ||
| none | ||
| 01 Jun 1999 | ||
|
How the product handles dates: There are no date inputting methods; dates are not utilized. Two-digit shortcut handling: Does not use 2-digit shortcuts. | ||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Basque)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Chinese - Simplified)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| See below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Chinese - Traditional)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Czech)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Danish)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Dutch)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (English)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Finnish)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (French)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (German)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Greek)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Hungarian)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Icelandic)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Italian)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Japanese)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Korean)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Norwegian)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Polish)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Portuguese (Brazil))
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| See below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Portuguese)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Russian)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Slovak)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Slovenian)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Spanish)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Swedish)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Data Access Components (MDAC) (Turkish)
| - | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| see below | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| Windows NT4 Service Pack 3 or higher, or Windows 9x operating systems. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| datetime data will correspond to the data source. | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 15 Nov 1999 | |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
|
Operational Range for Data: Dependent on Data Source (See Note D for more information)Release Dates: 1997-1999 What’s new: A separate Year 2000 compliance document is now available for the Microsoft Jet Database Engine.The Microsoft Jet Database Engine statement contains updated information on Microsoft Jet compliance. Please review it for the latest information. The latest release of MDAC is 2.1 Service Pack 2 (2.1.2.4202.3). The English (US) version is available for download on http://www.microsoft.com/data/. Localized versions will be posted as they are completed. The initial languages should be posted within 60 days of English (US).General information: Microsoft Data Access Components (MDAC) is a collection of data connectivity components. This collection includes MDAC core components (ADO, RDS, OLE DB, ODBC), plus several OLE DB providers and ODBC drivers. For customer convenience, the components are bundled together into a redistributable setup file, mdac_typ.exe. This setup is available through the web (at http://www.microsoft.com/data/), and through various applications and products.Separate year 2000 compliance documents have been made available for the core MDAC components, (ADO, RDS, OLE DB and ODBC). Known issues from those documents are already included in this summary. In addition, a year 2000 compliance document is now available for the Microsoft Jet Database Engine. This MDAC document provides compliance information for MDAC releases, versions 1.5 through 2.1 Service Pack 2. Version Localization: Version 1.5: Brazilian, Chinese -Simplified, Chinese -Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Portuguese, Polish, Russian, Slovak, Slovenian, Spanish, Swedish, Turkish Version 2.0 (with Visual Studio 6.0): Chinese -Simplified, Chinese -Traditional, English (US), French, German, Italian, Japanese, Korean, Spanish Version 2.0 Service Pack 1 (with Windows NT 4 Service Pack 4): Brazilian, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), Finnish, French, German, Hungarian, Italian, Japanese, Korean, Norwegian, Polish, Russian, Spanish, Swedish Version 2.1 (with SQL Server 7.0 and 6.5 Service Pack 5): English (US), French, German, Japanese, Spanish Version 2.1 Service Pack 1 (2.1.1.3711.6, shipped with Internet Explorer 5 only): Basque, Chinese -Simplified, Chinese –Traditional, Czech, Danish, Dutch, English (US), French, Finnish, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 1 (2.1.1.3711.11 Generally Available release): Basque, Chinese (Simplified), Chinese (Traditional), Czech, Danish, Dutch, English (US), Finnish, French, German, Greek, Hungarian, Icelandic, Italian, Japanese, Korean, Norwegian, Polish, Portuguese, Portuguese (Brazil), Russian, Spanish, Swedish, Turkish Version 2.1 Service Pack 2 (2.1.2.4202.3 Generally Available release): English (US) is available now, and the initial localized versions will be posted within 60 days.
The following table lists MDAC releases, compliance before remediation, and sources of remediation.
Note A (OLE DB compliance): The known Year 2000 issues for OLE DB data coercion library are: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a two-digit year less than 60, AND you do not specify a time as part of the date/time information THEN Data Convert (msdadc.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note B: SQL Server OLE DB provider compliance The SQL Server OLE DB provider (sqloledb.dll) does not use the core OLE DB Data Coercion library. Instead, it implements its own data coercion module. This module has the same Year 2000 issues described in Note A. Specifically: If you code to ADO, AND your ADO Recordset includes Date data types, such as: adDate, adDBDate, adFileTime, or adDBTimeStamp. AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). If you code directly to OLE DB APIs, the same case exists: If you are converting from a variant (BSTR, VARIANT or PROPVARIANT) to date datatypes, such as: DBTYPE_DATE DBTYPE_DBDATE DBTYPE_DBTIME DBTYPE_FILETIME DBTYPE_DBTIMESTAMP AND you are using a date format in which periods are used instead of slashes for date separator (01.01.98 instead of 01/01/98) AND you specify a 2-digit year less than 60, AND you do not specify a time as part of the date/time information THEN the SQL Server provider (sqloledb.dll) may translate your date as a time. For example, 01.01.01 (January 1, 2001) could be converted to 01:01:01 (December 30, 1899, 1:01:01am). Note C: Microsoft Jet Database Engine Compliance See Microsoft Jet Database Engine Year 2000 document for the latest information, including download locations for remediation. Note D: Oracle ODBC Driver and OLE DB Provider Compliance: There are no known issues in the Oracle ODBC driver. It should be noted, however, that the driver can expose server conversion behaviour already documented by Oracle in their white paper on year 2000 compliance. The following scenario results in incorrect "century" information from DATE data under certain circumstances. For instance, if you have data in a database (tablename='testdate') in a timestamp column (C1) with the following values: C1 --------------------- 2/21/1904 2/21/2004 2/21/2104 AND Oracle server and clients are installed with their "default" settings. As such, the default formatting for dates, including timestamps, is: DD-MON-YY. AND for the sake of this example only, your local "short-date" format of you WinNT client machine is set to 4-digit years. AND the current date/time on your Oracle SERVER is set to 1/1/2000. AND then, execute any of the following queries against your database:
[this is converting from a timestamp to a date.] (2) SELECT TO_DATE(C1) FROM testdate [default formatting] (3) SELECT TO_DATE(TO_CHAR(C1,'YY-MM-DD'),'YY-MM-DD') FROM testdate [more complex form of above, employs a user-defined date format mask] The results will appear as: C1 --------------------- 2/21/2004 2/21/2004 2/21/2004 Note: Only scenario number 1 must be executed via Microsoft's ODBC drive. Scenarios 2 and 3 can be executed directly through Oracle's tools. Oracle Server, as part of its white paper on Year 2000 issues, documents that certain implicit conversions are to be avoided if possible, but that if they must occur, they will follow certain rules, as dictated by the "format masks" applicable in different situations. With each of the above, the default format mask to be applied is the one stated above ("DD-MON-YY"), where Oracle's documentation again makes it clear that in those conversions some data may be lost. Specifically, the accurate century for dates may be replaced by the CURRENT century as specified by the date/time on the Oracle server machine. Microsoft's ODBC driver implements the functionality that enables "fn convert()" in scenario number 1. To do so, the ODBC driver relies on a built-in Oracle server function and the implicit conversion it entails. This provides the user with behavior consistent with, and as flexible as, the behavior users get from their Oracle server directly. With default date-formatting, attempting date-to-date conversions as outlined above will result in the outcome above.
Note E: ADO 1.5 Date Issue: The supported date range for MDAC starts no lower than the year 0100. In addtion to the case mentioned in Note D above, there is also an ADO case in which data containing years less than 0100 may not be converted as expected.
ADO 1.5. has a date issue. This has been fixed in all subsequent versions of ADO, starting with ADO 2.0. ADO 1.5 shipped with Windows 98, IE4.x and the NT Option Pack. Under the following circumstances ADO displays incorrect data if the actual year stored in the underlying data store is < 100. If the year stored in the underlying data store is less than 100, e.g. 98, AND the OLE DB provider does not provide a conversion from DBDATE and DBTIMESTAMP data types to an automation format. In this case ADO 1.5 will convert the date value itself and display 98 as 1998 or 01 as 1901. DBDATE and DBTIMESTAMP are OLE DB data types that allow a provider a mapping between how they store their data natively and how it gets presented to OLE DB. DBDATE is has the following structure: typedef struct tagDBDATE { SHORT year; USHORT month; USHORT day; } DBDATE; DBTIMESTAMP has the following structure: typedef struct tagDBTIMESTAMP { SHORT year; USHORT month; USHORT day; USHORT hour; USHORT minute; USHORT second; ULONG fraction; } DBTIMESTAMP; Since ADO is an automation object all data is exposed to the client via variants. There are conversions from DBDATE and DBTIMESTAMP to variants. If the provider is not capable of providing this conversion OLE DB provides a data conversion library they can use. In order to see this behavior you must have either a DBDATE or DBTIMESTAMP with a year field less than 100 and a provider that does not provide a means to convert its data into a variant as required by ADO, either natively or through our data conversion library. We know of no shipping provider from any vendor that fits this description. With ADO 1.5 even if you store the year as 0050 it will be altered to 1950 even though you may have intended the year 50 A.D. If you need to work with a year like 50 or 0050 in your data store then upgrade your client to ADO 2.x.
NoteF: General information: 1) Common date usage errors: Use 4-digit years when storing data or calling methods/properties of any of the MDAC data access Application programming interfaces (APIs). Using 2-digit years may reveal year-windowing in your backend or provider, where the boundary cases may not be well known (given an arbitrary backend data store). 2) Testing guidelines and recommendations: Since there is some "windowing" inherent in the year 2000 compliance features of most backend data stores, users should use 4-digit year formats in dates, particularly when placing data into a store and querying that store. 3) Operational range and early dates: If you're coding directly to OLE DB, and you’re converting a Variant BSTR to DBDATE, the date "0001-01-01" (January 1, year 1) may be interpreted as "2001-01-01" (January 1, year 2001). This issue affects the years 0001 to 0099. For this reason, the operational range should be considered to start no lower than year 0100.
How to determine which version of MDAC is installed, and whether you have compliant versions of OLE DB Data Coercion, Microsoft Jet Database Engine, and SQL Server OLE DB provider: In general, to check the version of a file it is often easiest to use the Find (file) command in the Tools section of Explorer. After selecting the file, right clicking allows you to examine the Properties which includes a Version tab.
***Please note, MDAC 2.0 SP2 is a super-set of MDAC 2.0 SP1. That is, MDAC 2.0 SP2 contains the MDAC components from 2.0 SP1, plus OLE DB providers for SQL Server and Oracle, and an updated oleaut32.dll.
2) Microsoft Jet Database Engine Since Microsoft Jet can ship outside of MDAC, the Microsoft Jet version should be checked in addition to the MDAC version. See
| |||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||||
| 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. | |
Microsoft Year 2000 Resource Center
MS Year 2000 Product Analyzer 1.0 (English)
| - | ||
| None | ||
| Microsoft Windows 95 operating system or later, Windows NT version 3.51 or later | ||
| System Clock | ||
| 22 Jun 1999 | ||
|
How the product handles dates: Microsoft Year 2000 Product Analyzer does not accept user-provided dates for any functionality. Microsoft Year 2000 Product Analyzer writes the current date and the date from the Year 2000 compliance database to the report in 4-digit year format. Two-digit shortcut handling: Not applicable
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Dutch)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| Noone | ||
| PC Bios | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (English)
| 04 Jan 1980 - 31 Dec 2035 | ||
| NONE | ||
| NONE | ||
| PC BIOS | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (French)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| None | ||
| PC Bios | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (German)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| None | ||
| PC BIOS | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Italian)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| Noone | ||
| PC Bios | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Japanese)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| None | ||
| PC BIOS | ||
| 28 Oct 1999 | ||
|
This document applies to MS-DOSV Japanese How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Korean)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| None | ||
| PC BIOS | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Portuguese)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| None | ||
| PC BIOS | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Russian)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| Noone | ||
| PC Bios | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Spanish)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| None | ||
| PC Bios | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 5.x (Swedish)
| 04 Jan 1980 - 31 Dec 2035 | ||
| None | ||
| Noone | ||
| PC Bios | ||
| 28 Oct 1999 | ||
|
How the product handles dates: MS-DOS recognizes dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 1900s. The MS-DOSÒ DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates within this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOSÒ file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOSÒ API the program must add 1980. Product compliance issues:
Recommendations: There are no patches available at this time and no plans to develop any patches. The commands described above are infrequently used and easily worked around. This date issue does not constitute a significant threat to the stability and/or functionality of the product as a whole. Testing guidelines and recommendations: Some PCs do have a problem that resets the system date to 1980 or other invalid dates when the computer reaches the year 2000. This problem is created by flaws in the computer hardware and in low-level BIOS software provided by other vendors. If users are going to test for this error, Microsoft recommends that executing the tests on a "test-bed" machine rather than a production machine. Please see the Windows Operating System Interactions with BIOS and Real Time Clock section in the Year 2000 white papers for further information.
| ||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (Danish)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| None | ||||
| None | ||||
| PC Bios | ||||
| 28 Oct 1999 | ||||
|
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (Dutch)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| None | ||||
| None | ||||
| PC Bios | ||||
| 28 Oct 1999 | ||||
|
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (English)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| NONE | ||||
| NONE | ||||
| PC BIOS | ||||
| 28 Oct 1999 | ||||
|
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (Finnish)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| None | ||||
| None | ||||
| PC Bios | ||||
| 28 Oct 1999 | ||||
|
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (French)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| None | ||||
| None | ||||
| PC Bios | ||||
| 28 Oct 1999 | ||||
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (German)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| None | ||||
| None | ||||
| PC BIOS | ||||
| 28 Oct 1999 | ||||
|
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Microsoft Year 2000 Resource Center
MS-DOS 6.0 (Italian)
| 04 Jan 1980 - 31 Dec 2035 | ||||
| None | ||||
| None | ||||
| PC Bios | ||||
| 28 Oct 1999 | ||||
|
MS-DOS is aware of dates beyond the year 2000. It does not display the full year, but will sort files correctly. Two-digit shortcut handling: If a 2-digit date is entered, the operating system will assume that the date entered is in the 20th century. The MS-DOS® DATE command does not correctly handle 2-digit dates from 00–79. This command returns the error message "Invalid Date" upon entry of 2-digit dates in this range. Dates entered using a 4-digit year are handled correctly (e.g. 01-01-2000). MS-DOS® file system APIs use a year offset from 1980 to store dates. When a program gets a date from an MS-DOS® API the program must add 1980. Product compliance issues:
| ||||
| 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. | |
Itemized List of products in each Volume
|
ALL COMMUNICATIONS OR CONVEYANCES OF INFORMATION TO YOU CONCERNING MICROSOFT AND THE YEAR 2000, INCLUDING BUT NOT LIMITED TO THIS DOCUMENT OR ANY OTHER PAST, PRESENT OR FUTURE INFORMATION REGARDING YEAR 2000 TESTING, ASSESSMENTS, READINESS, TIME TABLES, OBJECTIVES, OR OTHER (COLLECTIVELY THE "MICROSOFT YEAR 2000 STATEMENT"), ARE PROVIDED AS A "YEAR 2000 READINESS DISCLOSURE" (AS DEFINED BY THE YEAR 2000 INFORMATION AND READINESS DISCLOSURE ACT) AND CAN BE FOUND AT MICROSOFT'S YEAR 2000 WEBSITE LOCATED AT http://microsoft.com/year2000/ (the "Y2K WEBSITE"). EACH MICROSOFT YEAR 2000 STATEMENT IS PROVIDED PURSUANT TO THE TERMS HEREOF, THE TERMS OF THE Y2K WEBSITE, AND THE YEAR 2000 INFORMATION AND READINESS DISCLOSURE ACT FOR THE SOLE PURPOSE OF ASSISTING THE PLANNING FOR THE TRANSITION TO THE YEAR 2000. EACH MICROSOFT YEAR 2000 STATEMENT CONTAINS INFORMATION CURRENTLY AVAILABLE AND IS UPDATED REGULARLY AND SUBJECT TO CHANGE. MICROSOFT THEREFORE RECOMMENDS THAT YOU CHECK THE Y2K WEBSITE REGULARLY FOR ANY CHANGES TO ANY MICROSOFT YEAR 2000 STATEMENT. EACH MICROSOFT YEAR 2000 STATEMENT IS PROVIDED "AS IS" WITHOUT WARRANTY OF ANY KIND. CONSEQUENTLY, MICROSOFT DISCLAIMS ALL WARRANTIES, EITHER EXPRESS OR IMPLIED, INCLUDING THE WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. MOREOVER, MICROSOFT DOES NOT WARRANT OR MAKE ANY REPRESENTATIONS REGARDING THE USE OR THE RESULTS OF THE USE OF ANY MICROSOFT YEAR 2000 STATEMENT IN TERMS OF ITS CORRECTNESS, ACCURACY, RELIABILITY, OR OTHERWISE. NO ORAL OR WRITTEN INFORMATION OR ADVICE GIVEN BY MICROSOFT OR ITS AUTHORIZED REPRESENTATIVES SHALL CREATE A WARRANTY OR IN ANY WAY DECREASE THE SCOPE OF THIS WARRANTY DISCLAIMER. IN NO EVENT SHALL MICROSOFT OR ITS SUPPLIERS BE LIABLE FOR ANY DAMAGES WHATSOEVER REGARDING ANY MICROSOFT YEAR 2000 STATEMENT INCLUDING DIRECT, INDIRECT, INCIDENTAL, CONSEQUENTIAL, LOSS OF BUSINESS PROFITS, PUNITIVE OR SPECIAL DAMAGES, EVEN IF MICROSOFT OR ITS SUPPLIERS HAVE BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. SOME STATES DO NOT ALLOW THE EXCLUSION OR LIMITATION OF LIABILITY FOR CONSEQUENTIAL OR INCIDENTAL DAMAGES, SO THE FOREGOING LIMITATION MAY NOT APPLY TO YOU. THE INFORMATION CONTAINED IN EACH MICROSOFT YEAR 2000 STATEMENT IS FOUND AT THE Y2K WEBSITE AND IS INTENDED TO BE READ IN CONJUNCTION WITH OTHER INFORMATION LOCATED AT THE Y2K WEBSITE, INCLUDING BUT NOT LIMITED TO MICROSOFT'S YEAR 2000 COMPLIANCE STATEMENT, THE DESCRIPTION OF THE CATEGORIES OF COMPLIANCE INTO WHICH MICROSOFT HAS CLASSIFIED ITS PRODUCTS IN ITS YEAR 2000 PRODUCT GUIDE, AND THE MICROSOFT YEAR 2000 TEST CRITERIA. ANY MICROSOFT YEAR 2000 STATEMENTS MADE TO YOU IN THE COURSE OF PROVIDING YEAR 2000 RELATED UPDATES, YEAR 2000 DIAGNOSTIC TOOLS, OR REMEDIATION SERVICES (IF ANY) ARE SUBJECT TO THE YEAR 2000 INFORMATION AND READINESS DISCLOSURE ACT (112 STAT. 2386). IN CASE OF A DISPUTE, THIS ACT MAY REDUCE YOUR LEGAL RIGHTS REGARDING THE USE OF ANY SUCH STATEMENTS, UNLESS OTHERWISE SPECIFIED BY YOUR CONTRACT OR TARIFF.
|
||
|
Wednesday, November 17, 1999 © 1999 Microsoft Corporation. All rights reserved. Terms of use. This site is being designated as a Year 2000 Readiness Disclosure and the information contained herein is provided pursuant to the terms hereof and the Year 2000 Information and Readiness Disclosure Act.  | ||