Question

I have a SQL Server Express 2008 R2 instance running on my local pc.

• Authentication is ‘mixed’ so I can login using a Windows login and using SQL Server authentication.
• Named pipes are enabled
• TCP/IP is enabled
• Remote connections are allowed

I took the following steps to create a new login and database:

1. I logged in using SQL Server Management Studio Express and created a new login
2. I created a new database with the newly created login as owner

As you can see in the last screenshot there is a username “dbo” which ‘belongs’ to the login name “mylogin”. I’m trying to use the following connection string but it doesn’t work:

Data Source=(local)\sqlexpress;Initial Catalog=newdb;User id=mylogin;Password=mypass

The error log in SQL Server Management studio express states:

Login failed for user ‘mylogin’. Reason: Failed to open the explicitly specified database. [CLIENT: xxx.xxx.x.xx].
Error: 18456, Severity: 14, State: 38

If I change the User id in the connection string to “dbo” the following error is reported:

Login failed for user ‘dbo’. Reason: Could not find a login matching the name provided. [Client: xxx.xxx.x.xx].

I’m starting to turn really crazy now. I just have no idea on just how to get access to any database anymore… Is my SQL Server instance corrupt?

This problem only occurs when I try to connect from my ASP.NET applications. Connecting using SQL Server Management studio Express, using the credentials mentioned DOES work!

Answer 1

1. don’t try to map dbo to your login. dbo is a special user.

2. To connect to SQL Server using SQL authentication, you need to come in via a login, not a user (let’s leave contained databases in Denali out of the discussion for now). So you should never be trying to specify a database user (like dbo) in your connection string. I highly recommend creating a login and then creating a user at the database level with the same name that matches the login – this is far less confusing than trying to map login_foo to user_bar. I also recommend staying away from special words for users or logins (e.g. dbo).

3. I recommend learning the DDL and stored procedures necessary for setting this stuff up, and stop pointing and clicking through the UI. While the UI may seem quicker for some tasks, it’s terribly difficult to reproduce what you’ve done exactly, and it takes a lot of teeth-pulling to figure out what options you’ve set on the tabs in the dialogs that we can’t see. If you use a script, you can post a script and we can see it all without asking further questions, and you can also save that script and refer to it (which is going to be at least as good as your memory, but almost certainly better).

Here is how I would add a server login, put them in the newdb database as a user, add them to the db_owner (not dbo) role, and set their default database to newdb. Open a new query window in Management Studio and connect to master, then run the following:

USE [master];
GO
CREATE LOGIN Ropstah_test WITH PASSWORD = 'secure password';
GO
USE newdb;
GO
CREATE USER Ropstah_test FROM LOGIN Ropstah_test;
GO
EXEC sp_addrolemember 'db_owner', 'Ropstah_test';
GO
USE [master];
GO
ALTER LOGIN Ropstah_test WITH DEFAULT_DATABASE = newdb;
GO

Now your connection string from .NET should look like:

Data Source=.\SQLEXPRESS;Initial Catalog=newdb;User ID=Ropstah_test;Password=secure password;

If that doesn’t work, I’d validate that your ASP.NET app is running on the same machine as the SQL Express instance. The web server is also on your machine, right? Short of that, this should work, and if it’s not working, there’s some other variable involved that is not obvious. You should not have to make the user the actual database owner to connect, but if the above still doesn’t solve the problem, see if the below script changes the behavior or at least the error message that’s recorded in the log:

USE newdb;
GO
DROP USER Ropstah_test;
GO
USE [master];
GO
ALTER AUTHORIZATION ON DATABASE::newdb TO Ropstah_test;

This drops the user from the database and then re-adds them as the official owner (this is not the same thing as being in the db_owner role, which is essentially just shorthand to grant a template of permissions). This should not be necessary but it might help isolate why you can’t get this usually simple process to work.