The EXECUTE permission was denied on the object 'proc_FetchDocForUpdate'
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
July 22nd, 2009 5:50pm
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).My SharePoint Blog - http://www.davehunter.co.uk/blog
July 22nd, 2009 6:00pm
DaveMy 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
July 23rd, 2009 5:16pm
Hello,i have the same problem, do you have any ideas to resolve for this.Mario
August 3rd, 2009 12:44pm
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.
August 3rd, 2009 2:58pm
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).aspxThis procedureis stored in all content DBs.I think it's not a problem of the stored procedure or a custom webpart.
August 3rd, 2009 3:54pm
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)
September 2nd, 2009 5:59pm
Now I am getting this error. Did you guys find a solution?
October 2nd, 2009 6:55pm
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 library2.- 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 commentedToday 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.comIf 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 ... ????
October 5th, 2009 7:09pm
i'm having this error.Any fix ?
October 14th, 2009 4:57pm
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
December 1st, 2009 7:39pm
Will giving direct access on the specific sp/view allowed for SharePoint content databases? Will this affect the MS warranty for the product?
January 8th, 2010 3:34pm
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.)
May 10th, 2010 10:47pm
Hey following is the minimal permission required for app pool account. SharePoint Site Minimum Read Permission Sharepoint Server Add to WSS_ADMIN_WPG group Database Sharepoint Content DB (Site collection database) - db_owner permission Sharepoint Config DB (Config DB of sharepoint installation) - - db_owner permission If you are interested more about permission Read http://sharepointinstallation.blogspot.com/2010/12/minimal-permission-required-to-execute.html
December 12th, 2010 3:45pm