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
Related
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 am attempting to migrate from SQL Server 2005 to SQL Server 2008. Both of these database instances are hosted on 3rd party shared servers that I do not have full permissions to. They are using mixed mode authentication.
I am running into trouble setting up the new database the same way the old one was set up. Specifically, the new web-based control panel doesn't allow a dbo to be specified when creating a new database and then when using Red Gate SQL Compare to sync up the schemas I am having problems because some objects (that don't explicitly specify dbo in the script) are being created with the prefix of the user account rather dbo.
I have poured over the documentation trying to find a way to force my login "user1" as dbo to the "db1" database. I came to the conclusion that the script should look like this:
ALTER AUTHORIZATION ON DATABASE::db1 TO user1
Before running this script, the login "user1" already exists, but is not a user for database "db1". Note I had to submit this script to the support of my hosting company in order to run it. According to the hosting company the statement successfully executes, however when I compare the databases using SQL Compare the user "user1" has not been physically added to the database like it was under SQL Server 2005. When trying to add it using the script:
CREATE USER [user1] FOR LOGIN [user1] WITH DEFAULT_SCHEMA=[dbo]
I get the error message:
"The login already has an account under a different username"
I have tried dropping all of the other users from the database, but the error message still persists - which I find odd.
While I could just fix the scripts by explicitly specifying dbo, this would inevitably be a time bomb waiting to go off because if any new script were introduced that didn't explicitly specify dbo there would be a failure during synchronization. Since some of the scripts are from 3rd parties, this is not a good solution.
So my questions: Is there another statement that I need to run in order to add "user1" to the database as a user that is dbo? Is there anything that has changed in the implementation between SQL Server 2005 and SQL Server 2008 R2 that could cause these inconsistencies?
I am unfortunately not able to test to find an answer to the second one because I don't have another SQL Server 2008 database to test with and I don't have full access to do anything I want on this one.
The old database was created through a control panel which forced dbo to be specified and the new one doesn't allow dbo to be specified when creating a database.
From what i have gathered the following should suffice.
ALTER USER [user1] WITH DEFAULT_SCHEMA=[dbo]
The create wasnt working as it already existed.
I am currently encountering the following error when I try to specify a datasource from SSRS to SQL Server db (2008) using "credentials that are stored securely in the server" - this is specified as a windows account "s2\killian" with the option to "impersonate the authenticated user after a connection has been made" checked.
Msg 15157, Level 16, State 1, Line 1
Setuser failed because of one of the following reasons: the database principal 's2\killian' does not exist, its corresponding server principal does not have server access, this type of database principal cannot be impersonated, or you do not have permission.
Obviously this method of impersonation uses the SetUser() function behind the scenes and the MSDN documentation states that dbowner permissions are required in order to use this function. However I am getting the above error when using dbowner. I am not in a position to use sysadmin because of security policy.
Does anyone know how to get this mechanism of authentication and impersonation working without assigning sysadmin priveleges on the SQL Server database to the windows account used by the SSRS data source.
Is there a way of getting SetUser() to work without sysadmin priveleges?
Thanks
Killian
The clue is "the database principal 's2\killian' does not exist"
Any connection uses context change on the database side (eg SETUSER, EXECUTE AS etc) requires that the impersonated user exists in sys.server_principals and/or sys.database_principals.
Assuming you use an AD group, not individual logins, then this will cause the same error as above. Outside of any permissions. If you are db_owner, then you can impersonate at the database level. If you can't, then it's because of the previous paragraph.
I've always thought that this is an idiotic option for SSRS to have. MSDN says it uses SETUSER which is also deprecated. Ideally, you'd impersonate before connection which is possible for asp.net apps but don't know for SSRS (which is an asp.net app of course)
Sorry for lack of "do this and it works" answer...
I have been able to confirm as well that you must have Sysadmin rights to run the SETUSER function which appears to be the mechanism leveraged by SQL reporting services when "Impersonate the authenticated user after connecting" option is chosen.
MSDN's documentation for SETUSER mentions this but makes it sound like it should also be possible to run this function as just a db_owner but I have not gotten reporting services to work with an account that only has db_owner and I have not even been able to run setuser manually under an account that only has db_owner. The only way I have gotten it to work is with sysadmin privileges.
Recently I inherited a database from another programmer (created / stored with SQL Management Studio 2008), and I am having massive difficulties accessing, modifying, or even viewing the previously created databases.
Specifically, when I try to load one of the databases in SQL Management Studio I get the following error message:
"The database [database name] is not
accessible. (Object Explorer)"
I am connecting to the SQL server with windows authentication.
Anyway, is this a permissions issue left over from the last dev? (he's unavailable, unfortunately) And is there an easy work-around short of completely reinstalling SQL Management Studio?
Edit: Update:
Upon trying to access User Mapping, as suggested below, I got the following error message:
"One or more databases are inaccessible and will not be displayed in list."
Unfortunately, none of the databases I am trying to access appeared in the list, so I assume they are still inaccessible.
It could very well be a permissions problem. If you open Object Explorer in SQL Server Management Studio and expand the Security node (the one under the server instance, not the Security tab under the individual databases) and then expand the Logins node you'll see the list of logins that have been created on the server. Have a look at the properties of each of those and check out the User Mapping information. You'll be able to see which logins are mapped to which databases. It's possible the previous programmer only granted access to the database to certain logins. If you find a login that's mapped to the database you want, try changing the password of the login and then connecting to the database with that login and password. NOTE: be careful when changing the password as it may affect production applications that are using that login and password!
This message:
"One or more databases are inaccessible and will not be displayed in list."
Means that the user you are using right now cannot access to that db. If you can enter with a user that does have access and from that user change your actual user's rights through User Mapping, then you will see it.
You need a dba (or someone with dba equivalent access) to give you rights to the database.