Locked Row in database for key on Infopath Submission for Contribute Permission + below w/ Custom Event Reciever (ItemUpdating)

Question

Basic Rundown of Process: I am creating a Process wherein an InfoPath form is Submitted to a Library, certain managers will then have the ability to change a drop-down to either Approved or Rejected, and emails will be sent out appropriately. Users must be able to Add new forms and resubmit old forms with modifications, but not edit and re-save an existing form, regardless of its approved or rejected state.

Current Situation: Proof of Concept library and form are created and functional, and an appropriately designed workflow is created to run off of the ItemUpdating Event Receiver. Managers have Contribute or above, the Test User has Contribute. When added, the Event Receiver will properly redirect users to a nice error page if they try to edit the drop-down, and managers are able to take any action as expected. Users however cannot add new forms or resubmit existing ones.

Note that errors are cause when a user Clicks on an existing form or a the Add a new form and then attempts to submit the form, and receives

A Microsoft SharePoint Server State Service error occurred while processing your request. For more information, contact your server farm administrator.

Errors in Logs on User Attempts:

StateSqlSession.GetItemBytesInternal() Locked row in database for key (Guid1)_(Guid2) for x seconds

and then

StateManager.GetState() Locked data (Guid2)

Note that the Guids do not refer to the Web, Library, Library Items, or anything else i can see

Code:

public override void ItemUpdating(SPItemEventProperties properties)
{
    base.ItemUpdating(properties);

    if (properties.UserLoginName != @"Domain\Manager1" && properties.UserLoginName != @"Domain\Manager2" && ...)
    {
        properties.Cancel = true;
        properties.Status = SPEventReceiverStatus.CancelWithRedirectUrl;
        properties.RedirectUrl = "/SitePages/TestErrorRedirect.aspx";
    }
    else if ( /* Item has an Approval Value */ )
    {
        // Send email based Approve/Reject state and only if state has changed
    }
}

All references I find online to similar errors are due to SQL calls or in one case a file that's too big, but nothing related to this.

Answer 1

well, state service just use SQL DB to store user session data so Guids are most probably refers to current User session. Lock on a SQL table can appeared after too many requests at the same time. Probably your State Service is a performance bottleneck for a bigger farm? Could you please enable SQL profiling on State DB and check its performance and locks? other option is that web-based InfoPath form messed up User session id somehow but we can only try to render the form and track down SQL updates after this (only doablo for dev env)

Answer 2

We had the same problem with InfoPath. After analysis of servers,it turns out that the anonymous user authentication has been enabled on the web application server via IIS and not via SharePoint (unsupported configuration), causing side-effects on some queries which calls to forms.

We disabled anonymous access.This deactivation causes the functioning of forms again.

Rachid.

Answer 3

I suppose you have had a look here: http://social.msdn.microsoft.com/Forums/en-AU/sharepoint2010general/thread/e4d855f7-50e6-4b4f-b226-fc1efe4d4099 ? Wanted to post as a comment and not as an answer but it seems like I need more rep for that?

Answer 4

I was getting this error myself over the past week, and none of what I read applied to my situation. I have a IPFS form with a drop-down that is populated on load with data. On selection change, I run another data connection (a parameterized owssvr request) to fill some fields in the background. For most users, it works fine, but for the special submitter accounts I created, the first time you change the drop-down, the data lookups silently fail and the selection in the drop-down clears (due to rules logic). Trying to change it again causes IPFS to present the State Service error cited above.

I had been using a custom permission level called "Navigate" to try and replace Read access for specific scenarios. I wanted to give accounts appropriate permissions to land somewhere, but not to actually read files. For example, I might want to give a form submitter access to a list that has data which a form needs, but not actually give them read access to the site itself. It turns out that when I set up Navigate, I did not give it the SPBasePermissions.BrowseDirectories permission (labeled in the UI as "Browse Directories"), and this permission was required on the root level of the site where I was pulling the owssvr connection from. Once I added that permission level to the testing group I had created, the connection worked correctly and I stopped getting the State Service errors and Access Denied messages in ULS.

Answer 5

check your SQL server free space, probably related to it. source and may solve by this article by shrink and truncate your db.