I have an issue in regards to using SQL Server 2008 R2.
I recently had an issue with my computer and therefore I had to reboot windows and had to grant permission from one user to another user (using the security feature in the properties). When giving permission initially though, it through a "Access Denied" message.
After much research, it stopped producing this error (the user which I needed to grant permission too wasn't available), which then caused another issue to occur, but this time within SQL Server. It produces this message;
The database [dbName] is not accessible. (ObjectExplorer)
This error occurs when I try to select the drop down option to see the list of tables and stored procedures of the database within SQL Server. I found an explanation for this on the following link;
http://www.microsoft.com/products/ee/transform.aspx?ProdName=Microsoft+SQL+Server&ProdVer=10.50.1617&EvtSrc=MSSQLServer&EvtID=916
And I then tried to implement like so;
USE msdb;
GO
GRANT CONNECT TO [DBName\MyName] ;
CREATE DATABASE [DBNAME] ON PRIMARY
Using a script I created (luckily before this problem occurred) it through a whole lot of messages;
Msg 15151, Level 16, State 1, Line 1
Cannot find the user 'DBName\MyName', because it does not exist or you do not have permission.
Msg 262, Level 14, State 1, Line 2
CREATE DATABASE permission denied in database 'master'.
Msg 5011, Level 14, State 9, Line 1
User does not have permission to alter database 'DBName', the database does not exist, or the database is not in a state that allows access checks.
Msg 5069, Level 16, State 1, Line 1 ...
After this bunch of errors, I have become unstuck and therefore would much be grateful if anyone could give me some feedback in regards to what I could do to resolve this issue. Cheers.
Login with sa and expand Security > Login, right click on the username and then properties,
Click User Mapping and select the DB you want the user to access and then Ok
Generally it is a bad idea to grant permissions directly to logins. You should create role objects in the database, and all permissions in the database should be assigned to the roles.
Then when moving the database to another computer (or reinstalling) the only things you have to modify are server logins and role assignments.
One possible problem is that you have two instances of the database, so you have to deactivate one instance, if you have your database opened and accessible in your server explorer in Visual studio close connexion then go to windows services and stop and restart SQL server service (MSSQL) then go to Management studio and open your database, it should be opened and you can explore tables from Management studio.
Seems the database you are trying to access do not have admin privileges. Close SSMS and open it by Run as Administrator.
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)
A couple of weeks ago, I acquired a SQL Server database and started to develop my application with it with no problems since then.
Today, out of nowhere, I got this error:
Msg 262, Level 14, State 1, Line 1
CREATE TABLE permission denied in database 'master'.
This error is shown everytime I try to create a table, I tried SELECT, it works fine. I'm trying to understand what is wrong for hours, I only have one user, which I created when I setup the database for the first time, and I checked it's permission, it shows that I have permission to create a new table.
Also, everytime I connect to it with Management Studio 2016, it asks for me to add my IP, so I know that's not the issue.
I really have no idea how to continue from here, everything I found online people talk about granting permissions which it doesn't seems to be what is happening here, since I checked my permissions.
Any other thoughts?
The error says,You don't have permission to create table in master database..try creating in your database..
You can't create table in master database in SQLAzure.Master database in SQLAzure is readonly and is there, to hold information about roles,logins..
Check out this question as well:Please explain SQL Azure "master" database
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.
TITLE: Connect to Server
Cannot connect to tcp:ohimryXusa.database.windows.net,1433.
ADDITIONAL INFORMATION:
Hello,
I have a SQL Azure database. This database has a username / login that I want to use to access it. When I try to connect to the database by SQL Server Database Management Studio, I receive an error that says:
Cannot open database "master" requested by the login. The login failed.
Login failed for user 'mydbusername'.
This session has been assigned a tracing ID of '00000000-0000-0000-0000-000000000000'. Provide this tracing ID to customer support when you need assistance. (Microsoft SQL Server, Error: 4060)
I have other logins that I can successfully connect to the database with. I tried executing the following on my database, to ensure there was a user:
CREATE USER mydbusername
I receive an error that says:
Msg 15023, Level 16, State 1, Line 1
User, group, or role 'mydbusername' already exists in the current database
I verified the user existed by logging into the master database. Once there, I ran:
SELECT * FROM sys.sql_logins;
I wanted to ensure that 'mydbusername' had access on the database. So I logged in, with a more priveleged account, into my database and ran:
EXEC sp_addrolemember 'db_datareader', 'mydbusername'
EXEC sp_addrolemember 'db_datawriter', 'mydbusername'
EXEC sp_addrolemember 'db_owner', 'mydbusername'
The message said: Command(s) completed successfully.
At this point, we know a) There is a user with the name 'mydbusername'. b) There is a login with the name 'mydbusername'. c) We know that 'mydbusername' has 'db_datareader', 'db_datawriter', and 'db_owner' rights to the database.
I tried logging in via the management screen over the web. I was able to successfully login and execute queries. However, when I try to login via SQL Server Management Studio, I receive the message above. I am using
mydbusername#ohimryXusa for the "Login" field. I've verified that the password is correct. I also verified the Server Name is correct. What am I doing wrong? I really need this because I'm getting the error from my code. Thank you!
login failed is most probably cuased by wrong login/password combination.
Please make sure you are using the existing LOGIN, and not the USER while trying to login! Note that when you want to authenticate with SQL Server, you have to use the LOGIN created and not the USER. You have to find out which LOGIN is your "mydbusername" associated with.
It is good that you have the user, and that user is added to different roles, but a USER without associate login is nothing.
You may want to refer this documentation.
I know this is old thread, but I might help others who are facing the same problem...I created the user in master database without granting any special permissions - This resolved the problem. Looks like in Azure, all users that belong to user databases should also present in master database??!!
Because Azure uses database servers for multiple databases you can't just log into Management Studio (connect to the Object Explorer)
This would give you visibility to everyone's database whose on your same server.
To avoid this, simply close-out of the initial login prompt dialogue you're presented with on start-up and click 'New Query' once it closes.
You'll be prompted to connect - but if you go to connection settings and select your database as the initial catalog you'll be able to script your (and only your) database from there.
No object explorer - but at least you'll be able to directly script your DB.
I could see the below entries in the ULS log
02/08/2010 14:36:46.12 w3wp.exe (0x15F4) 0x18A0 CMS Publishing 8x0a High AppDomainUnloadListener.RegisterSelf() entered lock(this=15368010)
02/08/2010 14:37:25.59 w3wp.exe (0x15F4) 0x1744 Windows SharePoint Services Database 880i High System.Data.SqlClient.SqlException: Could not find stored procedure 'dbo.proc_GetDatabaseInformation'.
02/08/2010 14:37:32.53 w3wp.exe (0x15F4) 0x1744 Windows SharePoint Services Database 98rs High An error occured while trying to grant the user "X" access to the "Y" database on the SQL server. This may be expected if the caller does not have permission to perform this operation in sql server or if the database is read-only. To ensure that SharePoint functions correctly, manually grant this user access to the database before performing this operation. The user must also be granted access to the db_owner group in the database. The following information was provided with this error: User does not have permission to perform this action.
02/08/2010 14:37:32.53 w3wp.exe (0x15F4) 0x1744 Windows SharePoint Services Database 880i High System.Data.SqlClient.SqlException: User does not have permission to perform this action.
Any clues?
Whatever database user is calling this stored procedure will either need to have execute permissions for the stored procedure specifically or execute permissions in general. Your client program probably corresponds to one or more database users.
GRANT EXECUTE ON dbo.proc_GetDatabaseInformation TO [DatabaseUserName]
You have a permission denied issue. If you have permissions set on your database and you just added the proc 'dbo.proc_GetDatabaseInformation' you may need to give your users access to it. Specifically, any users that your website uses. Otherwise those users will not be able to call that proc and you will see the above error.
The error relating to dbo.proc_GetDatabaseInformation is a known issue with the Sharepoint 2007 infrastructure update - microsoft say you should ignore that error message: http://support.microsoft.com/kb/951695