FIX: SQL Server ODBC Driver Ignores Authentication Setting

When you use the SQL Server ODBC driver version 2000.080.0194, which was released with SQL Server 2000 and Microsoft Data Access Components (MDAC) 2.6 RTM, the authentication settings for ODBC data source names (DSNs) are ignored. The driver attempts to log directly into SQL Server using NTLM authentication (integrated security) without prompting for a user ID and password.

This can cause authentication failures, messages that database objects are not available, or unintentional modification of the wrong objects when copies of objects are maintained in multiple databases.

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 the Microsoft Knowledge Base:

Hotfix

The English version of this fix should have the following file attributes or later:

WORKAROUND

When possible, use an earlier version of the SQL Server ODBC driver such as the MDAC 2.5 version (3.70.0820).

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.

The SQL Server ODBC driver allows you to configure datasources to use either Microsoft Windows NT authentication (integrated security) or SQL Server authentication to log into the database.

The 2000.080.0194 version of the driver ignores the authentication specified in the data source name (DSN), and attempts to log into the database with NT authentication.

If the Windows NT account does not have permission to log on to the server, authentication errors are thrown. If the account has login permissions, but a different database is specified as the default database, "invalid object" errors can be thrown. If multiple copies of objects are kept in separate databases, unintentional modification of the wrong objects can occur.

This problem can cause unexpected behavior in numerous applications. For example, when you use Microsoft Access to link or query tables in a SQL Server database, no login dialog box is presented (because integrated security does not prompt for a login), and tables from the default database for the NT account are presented. No opportunity is given to change the database or login.

When you use Microsoft Project with a project that has been saved to a SQL Server database, a connection error is thrown followed by a dialog box that requires the user to clear the Use Trusted Connection check box and enter a valid user ID and password.