InfoPath Dev

Hi, I have an IP 2010 form and am using next number (auto incrementing) functionality that seems to be the recommended method that I've found online... (the process works fine, without fail...even resets the next number to 1 at start of a new year).

• Next Number list in SharePoint
• On Form Submit button, query the Next number list, read the max number and generate the form id. Then increment the number by one and push it back to the next number list via a map/submit.
• Then continue the rest of the rules (on the Submit button)..like push the form data to the appropriate list.
• (so everything happens on the same Submit button click)

OK, my question is: there is a concern that if 2 users submit at the same exact time. Even though everything happens in a fraction of a second, we envision that there could be an issue where one form is in the middle of the submit process (where the next number is pushed back to the list) and the other user's submit is trying to read the next number...causing it to end up using the same number, or would it lock data, or something blows up....

Has anyone ran into the situation?

Is there any other suggested method for next numbering that could prevent this from happening? Like is there something where this could be no longer a multiple step process?

I have SharePoint 2010, InfoPath 2010, qRules 6

thanks for any help!

Gwen

Hi Gwen,

Please check this webinar InfoPath: Protect your form's data integrity with document locks using Check-in/Checkout to prevent other users from editing the same form at the same time.

We also have Qdabra’s Check In and Out XTP which already has this logic - all you need to do is add the XTP to your form. The advantage of the XTP is that you can re-use it on other forms.

Would this appraoch work for you?

Regards,

Hi Don, thanks for your response. My form is a browser form, so I don't believe the check in /out option is applicable (let me know if I'm thinking incorrect). I did watch the webinar and it looks like the DBXL may work (I think towards the end he mentioned web browsers). I don't currently have this product (I only have qRules), but if it will work for browser forms, then I'll look into purchasing it. Can you tell me for sure that it this would be a solution for my situation, with web browser forms (the forms themselves aren't saved upon submit, instead the form data is submitted to SharePoint lists).  I did look at the Features list at the Qdabra site, but wasn't sure.

Thanks for all your help!

Gwen

Hi Gwen,

Both approaches will work for your scenario, but I believe that using qRules is suffice. As mentioned in the Qdabra’s Check In and Out XTP's page:

Benefits

• Automatic check out when a client opens a form
• Automatic check in when a client submits or closes a form
• Applicable to browser-enabled forms

The check-out is automatically triggered on form load - and we can easily add the check-in action at the save and submit buttons.

Regards,

Great, thanks! I'll look at it again.

Just to clarify, using check in/out works by only allowing one user at a time to fill in the form, correct? 

Since this is a browser form that is embedded on a sharepoint page with an InfoPath viewer webpart... if the form is checked out by someone else, what would the "form" on the page look like to a second user. Would is still open in the viewer web part?

Or would I need to build in a different section on the initial view of the form that conditionally shows if the form is currently checked out...saying "come back later"... and then conditionally show the remaining part of the form if the form isn't already checked out.

 Thanks!

Sorry, just read Hilary's blog post "Check that form out (or in) automatically"... and it answered by above question.... about how I can use a different view or message. Thanks again!

Hi Gwen,

Yes, that is correct. This will only allow one user to use the form. The XTP's form load logic includes an action that queries SharePoint and check if the form is currently checked-out to someone else. If that condition is true, the second person who is opening the same form will receive a message that the form is currently checked out - and from there, we can disable both the submit and save buttons. I haven't tested this on a web part, but theoretically it should work.

I'm glad to hear that. Please let us know if you are having issues with the Check-in/out XTP or if would like to use another approach.

Regards,