InfoPath Dev

I've seen a few messages about this error around the place and nobody seems to know how to fix it.

I've got users who are updating infopath forms stored on a form library.  Every now and then they get the following error:

'InfoPath cannot submit the form.An error occurred while the form was being submitted.

The form cannot be submitted to the following location: http://internalurl/MyForm.xml

The file is in use by another application or user. 

The files are not being used by other people.

Anybody found a fix fo this problem?

Cheers.

first error "Infopath cannot submit the form. an error occurred while the form was being submitted" can be caused by various things. e.g. submit code failing, adequate permissions not available on server, server too busy, server not available...

"the file is in use by another application or user" some times the forms get checked out and are not checked in, that is when these sort of errors come, or the form could be actually used by someone else...

 

The form does actually submit and a workflow runs sending notifications that the form has been updated.  The modified, and modified by fields are even updated correctly.

So its none of the problems you've suggested.  It's a random error that is not possible to reproduce with certainty.

you mean to say that even if the user recieves the error message, the form gets updated in the doc lib. that sounds sort of strange.

are you using managed code to submit the forms,

can you attach (reply -> options ->add/update)  the template so that we can have a look at it and might be find out what might be going wrong.

Are you using alternate access mapping for the site?

For example, "intranet:66666" and "myhost.mydomain.local" and "myhost" all point to the same site collection. If the form's dataconnection points to "myhost," and user accesses a previously submitted form with IE at the hostname "intranet:66666" the form will open, but the new Submit opperation will fail. Saving the changes still works. If the user accesses the same form with IE using hostname "myhost" the re-submit works fine.

In my case, I'm emailing the second user a link with a SharePoint Designer workflow. The workflow link ("Encoded Absolute URL") gives the "intranet:66666" hostname that no one uses. Anyone have an "easy" fix for that? I can build a dynamic string in the Designer workflow with the correct URL, but it would be nicer if Designer fetched the friendly hostname.

MOSS 2007 / InfoPath 2007

Hey even I am facing the same issue. the same form was running til yesterday and to day it is not working. Also I use views in the form. have taken a username filed. will compare the username value with the login id and then dispaly the appropritate views. I am able to submit the form for the first time , but am not able to update the form for approval. please help. Cheers Vijaya

We are having the same problem.  We have two forms (client, not browser-enabled) that behave the same way -- each form originally submits without any problem, but as soon as one of them is reopened, edited and re-submitted, we get this error (in use by another application or user).  However, after closing the form the edits that were made were saved.  Any further ideas about what might be causing this problem?

In my system the Submit dataconnection is explicitly coded to the "friendly" hostname. If the form is opened in the Infopath client via a different URL, i.e. with an alias for the same host, the submit operation will always fail. The error message names the current user as the "other user" who is locking the file. Since both URLs work exactly the same in the browser, the subtle difference in the addressbar is easy to miss, even for experienced users. So this may appear to be an intermittent problem, depending upon the exact navigation path the user takes to reach the document library in a particular visit.

Perhaps the edits were propagated to the server version of the form by a Save operation rather than Submit? Even if Save is disabled in the menu and toolbar, closing the form with unsubmitted changes may prompt the user to save changes.

Note that Infopath operates somewhat differently with SharePoint than Word or Excel library documents. Having the form open, even without any edits or checkout, still locks the server version of the file. It is quite easy for a user to forget the file is open and inadvertently prevent anyone else from changing it.

Finally got it figured out - it was an alias situation.  When we first started using our development system, we referred to it one way, and we began creating the forms based on that URL name, but by the time we got closer to asking for testing outside of our dept., we had changed the name slightly so that the URL for the form began one way and the users accessing the development database had a slightly different beginning on the URL they were using - conflicting with the data connections and other links in the forms.  Once I changed all data connections and links in the forms to reference the correct and current URL for our dev system, no more errors like this!

Thanks all. This post saved my life. Some of my users had similar complaints. All the servers in my company have a short URL and a long URL (full resolved). The data connections were coded with the long URL. But, when the form is accessed using the short URL - InfoPath would complaint about the file being checked out by another user. The problem is solved when the form is accessed using the long URL. thanks again.