I'm going trying to fix an issue that is burning and I've spent the last day without success.
I have a database server running SQL Server 2008, one database and one stored procedure.
The stored procedure logic contains the following sentence:
IF EXISTS
(
SELECT *
FROM dbo.sysobjects
WHERE id = OBJECT_ID( '<StoredProcedureNameHere>' )
AND OBJECTPROPERTY( id, N'IsProcedure' ) = 1
)
BEGIN
-- Do something here
END
Now, the issue:
If I run a query from the Management Studio script to execute the stored procedure under investigation it works correct and executes the "-- Do something here" logic.
However, exactly the same stored procedure invoked from a web service does NOT work.
I disabled for testing the entire IF EXISTS(---) block and retrieved information is the correct one.
My preliminary conclusion is there should be any permission setting ( I'm obviously not aware of ) configured for my user account over the database (and thus on sysobject table ) allowing me to successfully get the information that is NOT in place of the user account used by the web service to access the database.
Anybody knows any standard setting I should validate to have this working ?.
Hint - Both database and web service components were perfectly working. All this kind of issues started to come up right after the database server crashed and Operations teams needed to rebuild the database server. On asking about the state of the databases, they said they were able to backup the database and they must work as restored right after the new server was build.
Any assistance will be greatly appreciated.
Thanks,
Fortunatelly the issue was cleared out after Operations Team figured out the configuration for the domain account being used by the web service was incorrect. Couple of days looking for something that should not be an issue if the Config wiki page would be followed up step by step (everybody complains when there is no docu, but when it is available there is not being used at all ).
Anyway,if you had the same issue make sure to check the user info has enough privilegies to execute the stored procedure.
Hope this helps somebody else.
Thanks,
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)
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?
Background:
I have a site built in ASP.NET with Sql Server 2005 as it's database. The site is the only site on a Windows Server 2003 box sitting in my clients server room. The client is a local school district, so for data security reasons there is no remote desktop access and no remote Sql Server connection, so if I have to service the database I have to be at the terminal. I do have FTP access to update ASP code.
Problem:
I was contacted yesterday about an issue with the system. When I looked in to it, it seems a bug that I had solved nearly a year ago had returned. I have a stored procedure that used to take an int as a parameter but a year ago we changed the structure of the system and updated the stored procedure to take an nvarchar(10). The stored procedure somehow changed back to taking an int instead of an nvarchar.
There is an external hard drive connected to the server that copies data periodically and has the ability to restore the server in case of failure. I would have assumed that somehow an older version of the database had been restored, but data that I know was inserted 7 days and 1 day before the bug occurred is still in the database.
Question:
Is there anyway that the structure of a Sql Server 2005 database can revert to a previous version or be restored to a previous version without touching the actual data? No one else should have access to the server so I'm going a little insane trying to figure out how this even happened.
Any ideas?
Using SQL Server's built-in backup and restore mechanism, there is no means to pick only certain objects to restore. With transaction log backups, you can restore to a point in time which might be before a certain transaction or ALTER statement was made but that's the closest you get. There are tool's which will let you pick certain objects to restore however they work by either restoring the database to a copy and copying over the objects you want or reading the backup directly and copying out those objects. In other words, this is not something could have happened using the built-in tools accidentally. My guess is that someone accidentally ran an old script of the stored proc(s) that reverted it.
It would be trivial to change a stored procedure without touching any data, or any other stored procedure. How who why when, that's the problem.
One suggestion, run
select * from sys.procedures
and check the create_date and modify_date columns, for both your problem procedure and all other procedures in the database.
I've witnessed similar things happening with an app I have installed at one client location. Every so often the s'procs revert to an older version.
It's just one client, the app is installed at several others which have never had this issue, and they happen to be a school district as well. It happens about once every 3 months or so, and no one should be touching that machine. I'm not even sure they have anyone in house that would know how to open enterprise manager.
Out of curiousity, what backup software is your client using? and, after checking the creation / modify dates on the procedures, did a server reboot occur around that time?
The reason I ask is that my client has backup software that does some really weird things on that server. For example, on reboot it has to "play back" changes, including file operations, since the last successful backup. Also, is it installed in a VM?
Through Data Transformation Services (DTS) ? or if the scripts that set up the database are available someplace..
I have backed up and restored a MS SQL Server 2005 database to a new server.
What is the best way of recreating the login, the users, and the user permissions?
On SQL Server 2000's Enterprise Manager I was able to script the logins, script the users and script the user permissions all seperately. I could then run one after the other and the only remaining manual step was to set the login password (which do not script for security reasons)
This does not seem possible in SQL Server 2005's Management Studio, making everything very fiddly and time consuming. (I end up having to script the whole database, delete all logins and users from the new database, run the script, and then trawl through a mixture of error message to see what worked and what didn't.)
Does anyone have any experience and recommendations on this?
The easiest way to do this is with Microsoft's sp_help_revlogin, a stored procedure that scripts all SQL Server logins, defaults and passwords, and keeps the same SIDs.
You can find it in this knowledge base article:
http://support.microsoft.com/kb/918992
Run this:
EXEC sp_change_users_login 'Report'
This will show a list of all Orphaned users, for example:
Now execute this script here for each user, for example
exec sp_change_users_login 'Update_One', 'UserNameExample', 'UserNameExample'
This fixed my problem.
I use the SQL Compare product from Red Gate (http://www.red-gate.com/products/SQL_Compare/index.htm). There are other similar products around but I've had no reason to look for one as SQL Compare has never let me down.
You'll find it is useful for a lot more than the your current requirement as it will help synchronize all types of database object, not just login and permissions.
So basically I'm building an app for my company and it NEEDS to be built using MS Access and it needs to be built on SQL Server.
I've drawn up most of the plans but am having a hard time figuring out a way to handle the auditing system.
Since it is being used internally only and you won't even be able to touch the db from outside the building we are not using a login system as the program will only be used once a user has already logged in to our internal network via Active Directory. Knowing this, we're using a system to detect automatically the name of the Active Directory user and with their permissions in one of the DB tables, deciding what they can or cannot do.
So the actual audit table will have 3 columns (this design may change but for this question it doesn't matter); who (Active Directory User), when (time of addition/deletion/edit), what (what was changed)
My question is how should I be handling this. Ideally I know I should be using a trigger so that it is impossible for the database to be updated without an audit being logged, however I don't know how I could grab the Active Directory User that way. An alternate would be to code it directly into the Access source so that whenever something changes I run an INSERT statement. Obviously that is flawed because if something happens to Access or the database is touched by something else then it will not log the audit.
Any advice, examples or articles that may help me would be greatly appreciated!
Does this work for you?
select user_name(),suser_sname()
Doh! I forgot to escape my code.
Ok, it's working here. I'm seeing my windows credentials when I update my tables. So, I bet we missed a step. Let me put together a 1,2,3 sequence of what I did and maybe we can track down where this is breaking for you.
Create a new MSAccess database (empty)
Click on the tables section
Select external data
Pick ODBC database
Pick Link to the datasource by creating a linked table
Select Machine datasource
Pick New...
System Datasource
Pick SQL Server from the list and click Next, Finish.
Give the new datasource a name and description, and select (local) for the server. Click Next.
Pick "With Windows NT authentication using the network login ID". Click Next.
Check Change the default database to, and pick the DB. Click Next. Click Finish.
Test the datasource.
Pick the table that the Trigger is associated with and click OK.
Open the table in Access and modify one of the entries (the trigger doesn't fire on Insert, just Update)
Select * from your audit table
If you specify SSPI in your connection string to Sql, I think your Windows credentials are provided.
I tried playing with Access a bit to see if I could find a way for you. I think you can specify a new datasource to your SQL table, and select Windows NT Authentication as your connection type.
Sure :)
There should be a section in Access called "External Data" (I'm running a new version of Access, so the menu choice might be different).
Form this there should be an option to specify an ODBC connection.
I get an option to Link to the datasource by creating a linked table.
I then created a Machine datasource. I selected SqlServer from the drop down list. Then when I click Next, I'm prompted for how I want to authenticate.
CREATE TRIGGER testtrigger1
ON testdatatable
AFTER update
AS
BEGIN
INSERT INTO testtable (datecol,usercol1,usercol2) VALUES (getdate(),user_name(),suser_sname());
END
GO
We also have a database system that is used exclusively within the organisation and use Window NT logins. This function returns the current users login name:
CREATE FUNCTION dbo.UserName() RETURNS varchar(50)
AS
BEGIN
RETURN (SELECT nt_username FROM master.dbo.sysprocesses WHERE spid = ##SPID)
END
You can use this function in your triggers.
It should be
select user name(),suser sname()
replace spaces with underscores
you need to connect with integrated security aka trusted connection see (http://www.connectionstrings.com/?carrier=sqlserver)
How many users of the app will there be? Is there possibility of using windows integrated authentication for SQL authentication?
Updated: If you can give each user a SQL login (windows integrated) then you can pickup the logged on user using the SYSTEM_USER function.
My solution would be not to let Access modify the data with linked tables.
I would only create the UI in Access and create an ADO connection to the server using windows authenticated in the connection string. Compile you Access application as dbe to protect the VB code.
I would not issue SQL statement, but I would call stored procedures to perform the changes in the database, and create the audit log entry in an atomic transaction.
The UI (Access) does not need to know the inner works on the server. All it needs to do is request and update/insert/delete using the stored procedures you would create for this purpose. The server should handle the work.
Retrieve a record set with ADO using a view with the hint NOLOCK implemented in the server and cache this data in Access for local display. Or retrieve a single record and lock only that row for editing.
Using linked tables your users will be locking each other.
With ADO connections you will not have the trouble to set ODBCs on every single client.
Create a table to set the server status. You application will check it before any action. you can use it to close the server to the application in case that you need to perform changes or maintenance.
Access is a great tool. But it should only handle its local data and not be allowed to mess with the precious server.