Qdabra Database Accelerator

Re: DBXL and SharePoint enforced Check-in/out

Jim Cantwell — Wed, 25 May 2011 16:47:01 GMT

Thanks for the clarification. Your original post appeared to indicate it updated SharePoint even if another user had it checked out. I have tested with v2.4 and was able to successfully submit and have it update SharePoint while I have the document checked out. But even then, I see an eventlog message indicating the “file is checked out or locked” message. We will need to investigate this further to determine what in particular is causing that.

If you don’t see the documents updated in SharePoint, it may be related to the Office preferences. Can you provide details on what preferences you are using?

Re: DBXL and SharePoint enforced Check-in/out

JMdream — Tue, 24 May 2011 13:30:43 GMT

Hi Jim, the logs did show the message "...The file is checked out or locked for editing by.... '. It is frustrating however, that the person working with the form, is who checked it out to. However, as I explained in my previous thread, the DBXL and Back-end SQL are updated no problem when they hit the submit button (when back in the office), but because the SharePoint version is checked-out, when they hit the submit button on the form, they have to resort to then checking-in, and then uploading their more recent desktop version, over top of the older Sharepoint version (thereby adding a new version to the existing older version). We are going to live with this for now, as it is only a small group of people working with the forms., and have to work with forms in an offline/unconnected manner, until they return to the office and are connected.

By the way, I am finding that when a person checks-out the form it is not being saved to the local SharePoint documents folder on their system (even if they specifically state one in the Office preferences), so we had to resort to them saving the checked form to a location they wanted on the desktop, then when back in the office, they follow the procedure I mentioned above. Business is fine for now with this process. It is curious however that before we upgraded from 2.3 to 2.4 it appeared they did not have to do this last upload step, as the SharePoint version did get updated on submit, even when checked-out.

I will look at the LockDocument function for a future enhancement, at a later date.

Re: DBXL and SharePoint enforced Check-in/out

Jim Cantwell — Sat, 21 May 2011 02:56:12 GMT

Sorry for the slow reply. If the logs do not show an error saving to SharePoint, let's setup a meeting to look at your server configuration.

Re: DBXL and SharePoint enforced Check-in/out

JMdream — Tue, 17 May 2011 12:52:58 GMT

Hi Jim,

You have given me some ideas I think I will try. One of them is I will create a data connection to the form library and receive the check-out to, and Id of the document. I will then place a conditional statemrnt on the submit button that if the checked-out-to does not equal the person using the form, then the submit button will be hidden. This should stop both submission to DBXL and SharePoint, as I can capture that information and keep it in a hidden field in the form for the user even while offline. I can also try passing information back into the LockDocument of the DBXLDocumentService and querying it also and place condtional steatments on the submit button using this method. I will experiment. Thanks for the genisis of the idea.

Re: DBXL and SharePoint enforced Check-in/out

JMdream — Tue, 17 May 2011 12:04:11 GMT

Hi Jim,

Thank for your response. I am waiting for my administrator to send me the Qdabra event logs to see if I can see this item you mentioned. To apply a 'LockDocument' does that mean that I now have to add managed code to my infopath form, or is it accessbile through one of the DBXL webservices? If the user is working offline we will not have access to any online resources, until they open the document back in the office and hit the submit button. We are using InfoPath 2007, client-side, and I am having user choose 'offline' when they work out of the office, after having checked-out and saved locally the form, before leaving the office.

Re: DBXL and SharePoint enforced Check-in/out

Jim Cantwell — Mon, 16 May 2011 20:37:58 GMT

You should see an error in the Qdabra eventlog similar to below if the file is already checked out:

Caught exception saving document to SharePoint collection http://server/formlibrary. (DocType = 'TestDocType', DocId = 200) encountered a critical error and needs attention:

Microsoft.SharePoint.SPFileCheckOutException: The file "http://server/TestDocType/file1.xml" is checked out for editing by DOMAIN\user.

The SharePoint checkout should prevent the document in SharePoint from being updated, but will not prevent the DBXL version from being updated. Preventing the DBXL update requires a LockDocument call be performed.

Re: DBXL and SharePoint enforced Check-in/out

Patrick Halstead — Sun, 15 May 2011 21:53:24 GMT

Hi JMdream,

I'm going to submit this to Qdabra's Support alias. Sounds like there might be an issue with DBXL submitting when the file is checked out and I'll investigate whether this is a DBXL bug or not and whether it is fixed in DBXL v2.5 (release in March) or not. If not, we will open a high priority ticket to fix it (assuming there is no easy workaround). Since you are offline the default SharePoint lock won't work nor will the LockDocument/UnlockDocument web method in DBXL since both have a default 10-minute timeout when user goes offline.

Couple other ideas (possible workarounds while we are investigating ...

When the user clicks Submit, add a rule that tries to Checkout the document and if this fails, show a dialog box and don't do the submit. SharePoint shouldn't allow double checkouts so that should fail.
Add a checkout button to your form that sets a field in the form and submits it. If that field is set, disable the checkout button. If the field is equal to the current user enable the submit button. Add an action to the submit button rule that sets the field to blank before submitting and then closes the form.
If your form is doing a double submit because of a Side-by-Side install (i.e. submitting to DBXL and then SharePoint), you can still do option #1 above or you can just try to submit to SharePoint first and only submit to DBXL if that is successful.

More soon,

DBXL and SharePoint enforced Check-in/out

JMdream — Fri, 13 May 2011 19:57:34 GMT

We have employed DBXL2.4 with the document webservice to submit a form to both backend SQL and SharePoint. We have the Library in SharePoint enforcing check-in/out and major versioning (10). We are finding that even with forced check-out/in on the Library, other users are still able to open a checked-out form from SharePoint(even though it says read only) and submit the Infopath form (using the DBXL web service on the submit button), which then updates the back-end SQL and SharePoint, where, if we were working only in Infopath and SharePoint, this would not be allowed, because of it being checked out.

Our user work with the forms in an offline mode and only hit submit once back in the office and connected. All users have the same access as they all need to be able to edit and create forms.

How can I prevent another user from submitting a form that is already checked-out to another user, submitting to back DBXL and SharePoint?