This article was previously published under Q281646
This article has been archived. It is offered "as is" and will no longer be updated.
When you call the ODBC function SQLConnectW and supply non-null terminated strings for the data source name (DSN), user ID (UID), or password (PWD) parameters along with length indicators indicating the exact byte length of the strings, this may later cause an access violation (AV) in the ODBC connection pooling code.
NOTE: According to the ODBC specification, passing strings in this manner is correct. According to the specification, you are allowed to either pass the length of the string in bytes in the associated length parameter, or pass the SQL_NTS constant to indicate that the string is null-terminated.
This problem is due to a string length calculation issue in the ODBC connection pooling code.
To resolve this problem, obtain the latest service pack for Microsoft Data Access Components 2.6. For additional information, click the following article number to view the article in theMicrosoft Knowledge Base:
300635 INFO: How to Obtain the Latest MDAC 2.6 Service Pack
The English version of this fix should have the following file attributes or later:
Date Version Size File name Platform ----------------------------------------------------------- 01/04/2001 3.520.7104.0 24,848 Ds32gt.dll x86 01/04/2001 3.520.7104.0 221,456 Odbc32.dll x86 01/04/2001 3.520.7104.0 24,848 Odbc32gt.dll x86 01/04/2001 3.520.7104.0 37,136 Odbcad32.exe x86 01/04/2001 3.520.7104.0 41,232 Odbccp32.cpl x86 01/04/2001 3.520.7104.0 102,672 Odbccp32.dll x86 01/04/2001 3.520.7104.0 196,880 Odbccr32.dll x86 01/04/2001 3.520.7104.0 200,976 Odbccu32.dll x86 01/04/2001 3.520.7104.0 90,112 Odbcint.dll x86 01/04/2001 3.520.7104.0 12,288 Odbcp32r.dll x86 01/04/2001 3.520.7104.0 151,824 Odbctrac.dll x86
To work around this problem, supply null-terminated strings to SQLConnectW and use the SQL_NTS flag. Note also that this problem does not occur when using SQLConnectA (the ANSI version of SQLConnect).
Microsoft has confirmed that this is a problem in the Microsoft products that are listed at the beginning of this article. This problem was first corrected in Microsoft Data Access Components 2.6 Service Pack 1.
If you are experiencing this problem, you will see a stack similiar to the one below indicating an access violation in wcsncpy:
Microsoft Data Access Components 1.5, Microsoft Data Access Components 2.0, Microsoft Data Access Components 2.1, Microsoft Data Access Components 2.1 Service Pack 2, Microsoft Data Access Components 2.5, Microsoft Data Access Components 2.6