I have a problem creating a ODBC connection. I am using MS SQL server 2000. Local access. I create it in System DSN.

1. I select the "With SQL Server authentication using a login ID and password entered by the user rather than Windows NT. But the error message occur "Connection Failed: SQLState:'28000' SQL Server Error: 18452[micorsoft][ODBC SQL Server Driver][SQL Server] Login failed for user 'user1'. Reason: Not assosiated with a trusted SQL Server connection." after i click the OK button.

2. I have change the SQL server properties (configure) in the SECURITY tab under authentication from Windows only to SQL Server and Windows.

3. I'm using IIS version 5.1

Anyone has any idea on solving this problem.

Dani AI

Generated

Brief diagnostic notes and a tested checklist for SQL Server Error 18452 ("Not associated with a trusted SQL Server connection").

This error is typically caused when the server is only allowing Windows Authentication but the connection is attempting SQL (mixed) authentication. — because you already changed the server to "SQL Server and Windows" in the Security tab, the most common next step is to restart the SQL Server service (changes do not take effect until the service restarts). After restarting, verify the server truly accepts SQL logins by connecting with Query Analyzer or osql using a known SQL account.

If the server is in mixed mode but the login still fails, confirm the SQL login exists and is enabled. From Enterprise Manager (or with the SQL command below) create/verify a simple SQL login and give it database access:

-- SQL Server 2000: add a SQL login and give DB access
EXEC sp_addlogin 'user1','StrongPasswordHere';
EXEC sp_grantdbaccess 'user1','user1';
USE YourDatabase;
EXEC sp_addrolemember 'db_datareader','user1';   -- grant only needed rights

Notes about ODBC/IIS: when you build the System DSN, explicitly choose "With SQL Server authentication..." and (if you want the web app to reuse it) check "Save password". If the DSN is created correctly but the web site still gets 18452, test connecting from the web server machine with the same DSN and credentials outside IIS to rule out IIS account/permission issues.

About 's registry idea: changing HKLM permissions is rarely needed for 18452 and can be risky. Only consider registry ACL changes as a last resort (backup the registry first) and only if the DSN cannot be read at all. Finally, check the SQL Server error log after a failed attempt — it records the authentication mode and reason for refusal and is the fastest way to pinpoint whether the problem is mode, a disabled login, or a bad password.

are u using server 2003?
go to regedit
and change permissions to odbc to everyone, i hope it will work
[HKEY_LOCAL_MACHINE\SOFTWARE\ODBC\ODBC.INI\

Be a part of the DaniWeb community

We're a friendly, industry-focused community of developers, IT pros, digital marketers, and technology enthusiasts meeting, networking, learning, and sharing knowledge.