I occasionally see this error message

Source: Windows SharePoint Server

Category: Database

Event ID: 5214

Insufficient SQL database permissions for user '(web application pool account) in database 'SharePoint_AdminContent_' on SQL Server instance '(servername)'. Additional error information from SQL Server is included below.

The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate', database 'SharePoint_AdminContent_', schema 'dbo'.

I found some posts about granting account dbowner right or directly grant Execute permission and they dont sound very good options.

Do you have ideas of what caused this and how to fix this?

Thanks

The Admin Content Database is the database for the Central Administration. The application pool user should be the database access account and in my environment has dbo rights (which SharePoint configures when you install).

Dave
My Central Admin application pool has dbowner right on Admin Content db.
The account that got access denied is app pool account for Web application and it has dbowner right on all Content dbs. I wonder why doesit need to access Admin Content db. It's a member ofWSS_Content_Application_Pools database role in Admin Content db which hasExecute permission on serveral procedures.
Eric

Hello,

i have the same problem, do you have any ideas to resolve for this.

Mario

It seems there is some piece of custom code which is trying to execute a stored procedure which requires more privileges. May be you can try to remove the custom web part and seethe pageworks or not?

As you mentioned by default , the web application app pool should not be a dbowner and the default web parts should work fine.

We do not use custom webparts and the stored procedure 'proc_FetchDocForUpdate' is a standard procedure.
see link: http://msdn.microsoft.com/en-us/library/dd356420(PROT.13).aspx

This procedureis stored in all content DBs.
I think it's not a problem of the stored procedure or a custom webpart.

We have begun getting the same error, also on the AdminContent database. It started this morning, I've never seen the error before, and nothing was installed recently.
It's exactly the same, the apppool account does not have execute on that particular stored procedure. I checked the other content databases and all the permissions look exactly the same, so I don't think the db changed.

The odd thing is it did not occur at the same time as any scheduled task that I can find.

Correction: the one job that ran at the same timeis Usage Analysis, that's it. But it runs quite often and so far I only received the error once , 3 times in a row. (I have 3 servers in the farm)

Now I am getting this error.  Did you guys find a solution?

Hi guys,

I have the same error, but now I can reproduce it easily (but I don't now why):
1.- Go to a site with a document library
2.- Right click over a FOLDER and select "save shortcut" (or something similar, I have OS in Spanish)
3.- Open a new outlook message (or word document, etc) and insert an hyperlink. In the Address box of the dialog window paste the shortcut. The problem is that the address box doesn't allow more than 255 characters, so the link is "broken".
4.- Send the message or click over the new "broken" hyperlink and it sends you to an error page ("Cannot complete this action. Please try later."). There is a link that says something like: "Problem with the errors localizator with Windows SharePoint Services". If you click to see the HELP window: "voilà", the critical error returns to the log:

"w3wp.exe (0x0FD4)                        0x0E30 Windows SharePoint Services    General                        8kh7 High     Cannot complete this action. Please try later. 

w3wp.exe (0x0FD4)                        0x0FE0 Windows SharePoint Services    Database                       6lcf Critical Insufficient SQL database permissions for user 'MOSS_WEBAPPxxx' in database 'SharePoint_AdminContent_xxxxx' on SQL Server instance 'SQLServerxxxx'. Additional error information from SQL Server is included below.  The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate', database 'SharePoint_AdminContent_xxxxx', schema 'dbo'.  "

It seems that it only happens in one of may Web Apps so I'll look for the differences. I hope it could be useful.

Ciao.

06/oct/09 - MORE NEWS
- The link that reproduces the error appears if in the web.config of the web app:
      1. CallStack = false
      2. The "GlobalErrorHandle" line is commented

Today it was "solved"???:
- In the SQL Server we give "db_datareader" permission in the SharePoint_AdminContent_xxxx DB to the MOSS_WEBAPP_xxx user. We repeated the prove and the error had disappeared. Then we removed the "db_datareader" permission for MOSS_WEBAPP, and the error continued missing, so now we don't get this error anymore... but I don't know why (MOSS = X-file). Maybe tomorrow this error will return.

 13/oct/09 - AND MORE...
- URL used to reproduce the error: http://server:port/_layouts/help.aspx?Lcid=1027&Key=WCMNavigationInheritance.com
If we add the Execute Permission to the rol WSS_Content_Application_Pools over the SharePoint_AdminContent_xxxx DB then the error returns for other stored procedures or views. The complete list is:
- proc_FetchDocForUpdate
- proc_GetWebMetaInfo
- proc_UpdateDirtyDocument
- proc_UpdateListItem
- and the view: UserData (need "Select" access)
but again if instead of giving individual permissions we give the db_owner rol to the WEB_APP user, repeat the test and eliminate the db_owner rol for this user, then the error disappears ... ???? 

i'm having this error.
Any fix ?

i'm having this error.
Any fix ?

This is what I found.
http://share-point.blogspot.com/2009/11/moss-event-5214-execute-permission-was.html

Will giving direct access on the specific sp/view allowed for SharePoint content databases? Will this affect the MS warranty for the product?

Does anyone know if a recent SharePoint CU solves this problem? 

We recently rebuilt our farm with new Server 2008 servers and started receiving this.  But our SharePoint patch level is only at service pack 2.  (I'm willing to consider the execution rights fix but I would rather rely on a cumulative update doing this stuff for me.)

I had a similar issue running the SharePoint Products Configuration Wizard. The error was "The EXECUTE permission was denied on the object 'proc_MSS_GetLease'." The wizard got stuck on step 8 of 9, and the log was filled with this error. The referenced article showed a clue, adding security principals to the group. In my instance, it was a different database, and the group was 'SPSearchDBAdmin'. I added "Local Service", "Network Service" and the farm account to that group and the error resolved. Only 2 of the three accounts were in the group. This probably happened when I tried to resolve an error that showed up in Central Admin under health checks about the wrong account being tied to a particular service. So I changed it. And it broke this process. I'm surprised it would keep retrying indefinitely though, and not stop t