Have a SQL Server 2008 db which I connect to the Windows Authentication .. has worked good for 7-8 months .. but now when I come to work today it no longer worked to connect, without that I had done something
Error message was:
Can not open user default database. Login failed.
Login failed for user 'Jimmy-PC \ Jimmy'.
where the first is the computer name and the second is the user. The problem seems to be that it tries to connect to the default database. Have tried to change it without success .. I do not have sql server management tools for sql 2008 but only to 2005, someone who has similar experience? who have not touched anything said over the weekend and it worked last Friday without any problems.
The user's default database is offline. the thing that changed since yesterday is that your database had failed, for whatever reason.
You need to log in with a different account, one that does not have a default database, and inspect the state of the database. If you do not have such an account, then you can use an administrator account. If the administrators group is not granted login into SQL Server then see this article Troubleshooting: Connecting to SQL Server When System Administrators Are Locked Out.
Once you can log in, the only tool you need is sqlcmd.exe, which is installed on your machine. Look into sys.databases, the state_desc column will tell if a database is offline. You can try a to ALTER DATABASE ... SET ONLINE and see if it recovers, but that would be unlikely. Your best choice will be to apply your disaster recovery plan and restore the database from the backups you keep for it.
It is strange that it just stopped working. Have you checked the status of the user's default database? Make sure the database exists and is online.
To find the user's default database run the following command using sqlcmd.exe
select dbname from syslogins where name = 'Jimmy-PC \ Jimmy'
I have seen this error when recovering a system and the user's default database hadn't been restored yet and another time when a database was in "Recovery" mode.
I would also make sure that the windows account is not disabled.
If you find that you need to change the user's default database you can use a T-SQL command, see the following question:
How do I set the default database in Sql Server from code?
Related
Over the weekend my Dev server experienced a very interesting issue. I have a scripts that periodically take several databases offline, and then bring them back online again. They ran, and took all the specified databases offline, but then failed to bring them online again, the specified error message was:
Msg 5011, Level 14, State 7, Line 4 User does not have permission to
alter database 'XXX', the database does not exist, or the database is
not in a state that allows access checks. Msg 5069, Level 16, State 1,
Line 4 ALTER DATABASE statement failed.
This doesn't seem right to me as they we're run from a user account that has the following properties set:
I further validated that it wasn't a permissions issue by logging on to that server, running SSMS as an Administrator and logging in with my windows credentials (also a admin account) and executing the following SQL on the offline database:
USE [master]
GO
ALTER DATABASE [XXX] SET ONLINE
GO
With the same results...
I've looked at the SQL logs for more details about the specific error, however there are no entries associated with this issue. I can reproduce this issue on every database on this particular server. The only way I've been able to get the databases online is by de-attaching and reattaching them.
Most other stack overflow tickets involving this error message are specific to one database or a specific user account. My issue spans all databases and all admin users I've tried so far, also my issue occurred on a script that had previous worked fine on this server and account, clearly something has shifted over the weekend that is causing this query to now fail. I wonder if anyone else has experienced this issue before?
Update 1
This post talks about how file security can trigger this error message, I granted full access to the user group on one of the databases, then reran the online command, no luck. My SQL Server service is running under a service account that is part of the "Administrator" user group and has full access to all database files.
Update 2
All sorts of interesting idea's put forward here, also discussed here. Lots of commands and ideas on how to repair damaged databases with a several combinations of repair like SQL command, unfortunately none of them work in my situation, they either won't run on offline databases, or after detach and reattachment do not report any errors. Of course, there are always a number of posts simply insisting that the solution is permission based and that running: GRANT ALTER ON DATABASE will resolve all issues. For my admin user account it shouldn't make a difference, but it's a moot point as I can't even run that command on a offline database...
Finally tracked down the issue, apparently we had a completely unrelated SQL database instance on the same server in recovery mode. While it was recovering we we're unable to bring any offline instances online. Detach/re-attach would work, and we could restore the database just fine, but just not set it online.
The separate database finished recovering and we are now able to run the command without issue. I suppose in the future, if I don't care about the database that's in recovery(which I often don't) I'll following the linked steps to get rid of it, before restarting SQL Server and proceeding:
Stop SQL Server
Delete MDF + LDF
Start SQL Server
Restore (may need to drop first, comes up suspect)
I am trying to perform a database backup in SQL Server Management Studio 2008. We do this backup yearly, and have had no issues up until today. The error says
The user's password must be changed before logging on for the first time.
I have checked the users on the database, and none of the accounts are flagged for a password change. The network location we are backing up to has the shared permissions set to read/write. Please help
I have been asked to maintain a site created in ASP classic that uses a SQL Server database.
I was given the database in the form of a backup. I restored the database on my local computer and created a DSN connection to it. However when I attempt to load my site, the stored procedures the site relies on give an error that execute permission was denied.
The stored procedures in question have a user named UserSecure showing as the only person with EXECUTE permission, I have tried creating a user by that name but that does not work, even though I can manually login to SQL Server Management Studio using UserSecure trying to connect from the web page using those credentials gives a login failed error.
If I run sp_helplogins my Windows credentials are shown as being owner of the database, and I can in fact execute from within SSMS but not from an ADO connection.
On another note the connection in the webpage was coded like this, I am not familiar with the application part of the connection. Perhaps this is part of the problem? I have tried connecting with a DSN and DSN-less connection and can connect but not do anything with the database?
You should make sure the database server login is mapped to the appropriate database user (this problem crops up often when dealing with database backups). If it is not, then you need to fix the mapping. Fortunately, there is a command called sp_change_users_login that you can use to fix this problem.
First, check if your login is mapped to your database user. Using SQL Server Management Studio (assuming SQL Server 2008), look under Security/Logins for UserSecure. If you see it in the list, double click on it and select User Mapping. From there, locate the database you are trying to connect to, and see if UserSecure is mapped to that database. If it is not, you may be able to fix it using the following command (assuming UserSecure is the name of both the login and the user):
EXEC sp_change_users_login AUTO_FIX, UserSecure
See MSDN for more info on sp_change_users_login:
http://msdn.microsoft.com/en-us/library/ms174378.aspx
One issue that has bitten me a few times:
If your stored procedure (or view) requires permission from a user (let's say userA), and the stored procedure calls another database's table or view (say viewB), it is not sufficient to just make a login on viewB's database, you must also explicitly grant userA permission to select/execute/etc. on viewB (which in turn requires a user on viewB's database)
So in your case, you may need to explicitly grant UserSecure execute permission on a stored procedure on an existing database referenced by the one you restored.
This may not be the most elegent fix, but I quit focusing on the one procedure and instead granted execute permission to the guest user on the entire DB. Since this is only running on my personal machine security is not an issue and it seems to have fixed the problem.
Know the problem all too well,
The ID of the user(name) will be different from the backed up database to the restored one. MSSQL stores the ID of the user and not the username (text), so the ID will be different (99% of the time) per machine and backup. So when the ID does not match you don't have access.
All you need to do is delete the user and recreate it, make sure you do it in both places:
Delete the user from the database first:
DATABASE -> SECURITY -> USERS -> Right click (username) + delete
Then goto
SECURITY -> LOGINS -> Right click (username) + delete
Then recreate the user and give the account the correct permissions and you're all good.
I got an error message in my Log Reader Agent:
The process could not execute 'sp_replcmds' on 'Database Name'.
I created another agent profile with a large query timeout and a min value to batch, but it still doesn't work.
Can someone help me?
I'm using SQL Server 2008 and I'm trying to do a replication between databases on different servers.
It could be possible that owner of the database could be someone other than what you have permissions for. Below there's a simple command to change ownership...if you have the rights to do so.
--TSQL Code--
USE PublishedDatabase
GO
EXEC sp_changedbowner 'sa'
GO
There are a lot of things that can cause this error (which include, but is not limited to):
The database has been publication disabled
The account trying to run the log reader agent doesn't have the ability connect to the publisher server
The account trying to run the log reader agent doesn't have permission to run sp_replcmds
In my experience, there's a little more to the error in the replication monitor. Is this the case for you?
This could be due to Owner is not set for the database.
You can check by right clicking on database then choose Property and go to File Table and the Owner selection should be there.
I have taken a copy of a database home with me so I can do some testing. However when I try to run a stored procedure I get Cannot open user default database. Login failed..
I have checked and checked and checked I can open tables in the databases login to sql management studio and access the default as well as other databases any ideas?
Possibly a corrupt user it was from sql 2000 at work to 2005 at home
EDIT: Mine was from 2005 to 2005. Not sure if this will work for your case...
I had a similar problem. For me, when I detach or create a back up and then re-create the database, it will loose connection to users. User I've been using is still there under Login but it would fail to log in.
In my case, I was able to log in by deleting the User under the database -> security -> users, not the user that's in the root sql server users list.
Then go to root users list and reassign database mapping or create user if not exists.
Hope this helps.
This is a shot in the dark, so forgive me if it just wastes your time.
Another poster mentioned that a given user has an id for the system and an id for any given database. This can be proven out by comparing sid's between the master.sys.syslogins and dbname.sys.users for the same login / user name. If you restore a backup from another sql server that has it's own copy of the master databases, the sids won't match.
Sql Server 2005 doesn't allow direct editing of system tables with out a lot of pain. To help out with these mis matches, they added a stored procedure to help you fix them:
USE dbName
GO
sp_change_users_login #Action='Report'
That will show you what users have a dbName.sys.users entry, but no master.sys.syslogins one - or where the name exists in both, but differ by sids.
If it shows that your user is out of synch, the procedure also has a mode to change the linking:
USE dbName
GO
sp_change_users_login 'Update_One', 'userNameInDbUsers', 'UserNameInLogins'
If the sid mis-match isn't your problem, I've also seen really screwy stuff with Sql Server 2005. The gui is especially buggy. To fix a problem like this, I had to actually drop the syslogins entry (via the gui or DROP LOGIN command )
sp_change_users_login: http://msdn.microsoft.com/en-us/library/ms174378(SQL.90).aspx
Drop Login syntax: http://msdn.microsoft.com/en-us/library/ms188012(SQL.90).aspx
I had the same issue and I fixed it with:
C:\> sqlcmd -E -d master
1> ALTER LOGIN ***** WITH DEFAULT_DATABASE=master
2> GO
Where ***** is your username.
(If you are using a domain username: [*****])
Edit:
Where ***** could be:
username if the user is local
[username] if the user belongs to the actual domain
[domain\username] if the user belongs to another domain (not tested)
I moved 8 databases from SQL Server 2000 to SQL Server 2005 and onto a whole different computer. I normally like to know what stored procs are doing so I dug a little bit and found that the actual command is ALTER USER.
It's what everybody else has been saying. The users get disassociated when you detach and reattach databases in SQL Server 2005. I find this behavior most annoying, as I didn't see that behavior in SQL Server 2000.
The T-SQL to fix this issue looks like this:
USE AdventureWorks;
ALTER USER Mary5 WITH NAME = Mary51;
GO
This MSDN article talks a bit more about this:
http://msdn.microsoft.com/en-us/library/ms176060.aspx
I just solved this issue. My default database was AdventureWorks2008, so as an Administrator, I ended up removing my login from the server. Then running the following to recreate my user
CREATE LOGIN [NT\mylogin] FROM WINDOWS WITH DEFAULT_DATABASE=[Master], DEFAULT_LANGUAGE=[us_english]
GO
My understanding is that Logins are stored in the server, whereas a User is an assignment of a login to a database (correct me if I'm wrong).
Therefore, you cannot move Logins by detaching/attaching databases, and the solution would be to create a database User connecting a (valid) login to the copied database.
http://benharrell.wordpress.com/2007/01/15/cannot-open-user-default-database-login-failed-login-failed-for-user-username-microsoft-sql-server-error-4064/
ALTER LOGIN works only in SQL 2005 and up.
To change the default database for a user in 2000 use
EXEC master.dbo.sp_defaultdb #loginname = N'BuiltIn\Administrators', #defdb = N'master'
I found this out the hard way when I set the builtin\administrators account to default to the application db and it went Offline somehow and I could no longer login. Using Management Studio, you can set the option to login to master but you must run the above command before any other operation will work, less you get the default database is unavailable error.
As was mentioned before, the login mapping to that user account probably became disassociated during the move. Or, you moved it without creating the credentials it was expecting, in which case, you'd need to create the login first...
If it was a backup set and you are restoring it, however, there is no way (that I know of) to reassociate the login to the user via the management UI. Instead, you have to use:
exec sp_change_users_login update_one, 'user', 'login'
to get it to restore the link.