I got this error in a production environment today. The actual stack trace I was getting was something like this:
at Microsoft.SharePoint.Library.SPRequestInternalClass.UpdateRoleAssignment(String bstrUrl, Guid& pguidScopeId, Int32 lPrincipalID, Object& pvarArrIdRolesToAdd, Object& pvarArrIdRolesToRemove)
at Microsoft.SharePoint.Library.SPRequest.UpdateRoleAssignment(String bstrUrl, Guid& pguidScopeId, Int32 lPrincipalID, Object& pvarArrIdRolesToAdd, Object& pvarArrIdRolesToRemove)
No need to say that we had to resolve this issue as quick as possible. Searching the Internet gave me many references to this exact error message (such as http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=2863393&SiteID=1 or http://forums.microsoft.com/MSDN/ShowPost.aspx?PostID=1335022&SiteID=1) with the top causes of the problem being:
1 – The SQL Transaction Log database is full
2 – The windows account used to access the database doesn’t have enough permissions to the database.
However none of them was the case for us. Trying to get more info on the issue I run SPTraceView which saved the day. After getting the error message in SharePoint, SPTraceView immediately showed the error below:
Computer xxxxxxxxxxx, Date 02 Jul 2008
|
Server |
Time |
Severity |
Product |
Category |
Message |
|
xxxxxxxxxxxx |
13:07:09.77811 |
Unexpected |
Windows SharePoint Services |
Database |
Unexpected query execution failure, error code 916. Additional error information from SQL Server is included below. “The server principal “xxxxxxx\Svc_Moss_AppPool” is not able to access the database “Profiler_Trace” under the current security context.” Query text (if available): “{?=call proc_SecUpdateUserActiveStatus(?,?)}” |
The message immediately rang a bell. We had started some SQL Server profiling and created some profiling triggers few days ago and looks like the application pool account didn’t have enough rights to our temporary profile database. That’s what I call a great catch that shows the power of SPTraceView. So if you haven’t got this tool in your arsenal yet, you should get it NOW from here.
Thanks for the solution to this problem. This tool makes it easy to view logs associated with the WSS. I was always of the opinion this error was related purely to Log size, but in this case it was a specific permissions issue, which without this tool could have spent a lot longer figuring it out. Thanks again
Comment by stuconz — 11 February, 2009 @ 9:30 pm
Hi Hristo, this fixed my problem too mate… thanks
Comment by Allan Ranola — 9 July, 2009 @ 11:46 pm