2

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.

4
  • By any chance is State Service Application not configured at the farm level ? Can you confirm this..
    – ArkoD
    May 24, 2012 at 9:26
  • It is in fact there and started, wouldn't my InfoPath forms not work at all if it was not there and started?
    – Zork
    May 24, 2012 at 14:11
  • I would try to move base.ItemUpdating(properties); line to "else if" block May 29, 2012 at 12:08
  • @Ivan: Tried, did not fix the issue.
    – Zork
    May 29, 2012 at 16:31

5 Answers 5

3

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)

1
  • thank you very much for the info, I will look into it as soon as i am able. If nothing else this sounds like a great place to start looking!
    – Zork
    Jun 2, 2012 at 20:05
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.

0

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?

1
  • Thank you for the post but unfortunately this is a development site where only I work, the permissions are as they should be, and I tested it with various settings.
    – Zork
    May 29, 2012 at 15:07
0

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.

0

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

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.