Submitted form tries to save as form1

I have a form in a SharePoint 2010 forms library, when the user creates a new form they submit it so that a "voucher number" is created. They then go on to edit the form and finally save.
The form submit action specifies how to name the form and that the form is to remain open when submitted. This is fine.
However after it is submitted and the form is further filled out and saved, IP asks them if they want to make changes to "Form1" and asks them where to save.
The behaviour should be simply update the form that has already been submitted - the one open in front of them.
Any ideas why this could be happening?
LVL 29
QPRAsked:
Who is Participating?
 
CloudedTurtleConnect With a Mentor Commented:
When you submit the form it is saved, but it is saved in a manner that IP client doesn't recognize the submit location as its saved filename path. Because you have only opened the template XSN directly. When you submit and then open the file you aren't opening the XSN (like you would when you create a new item) you are opening the XML file. The instructions at the beginning of the XML file tell it to use the IP template (XSN) to display the form.

This is the reason for your behavior.

The only way that I see you could achieve what you are looking for would be to essentially use 2 submit paths

1) initial submit used to get your item number and submit the form to the library. (this I would expect to set a form value that you would use in your submit rules in order to determine if you need to run the steps again)
2) second submit that really just updates the XML (basically it skips all the steps/rules for calculating the form name because it should already have it)

So, your submit actions would look something like this:
a) check "voucher" field if blank goto b) else goto c)
b) calculate voucher name and submit form (allowing overwrite)
c) submit form (allowing overwrite)

as mentioned before, you should hide the "save" button from the ribbon and use buttons. This is the easiest method to prevent confusion of your users.

Hope this helps. Keep in mind that the initial save isn't broken, its just not working the way you are expecting it to work. You cannot save the XML file and force IP client to suddenly switch the current file from the template XSN to the XML file.

-CT
0
 
FastFngrzCommented:
The solution is to create a field to hold the filename, and generate that filename by either a default setting or by a rule.  Then use that filename as part of the submit action.

Make sense?
0
 
QPRAuthor Commented:
The filename is created using a rule and this filename is used when they first submit the form.
If you look in the library the file is visible - BUT before they can use the save button in the normal way, the form needs to be closed and re-opened.
If they submit, close the form, open the form and click save then all works as expected.
If we open an existing form and click save, again, all is fine.
This problem only occurs when they create a new form, click submit and then subsequently try to save the form.
0
Cloud Class® Course: Microsoft Exchange Server

The MCTS: Microsoft Exchange Server 2010 certification validates your skills in supporting the maintenance and administration of the Exchange servers in an enterprise environment. Learn everything you need to know with this course.

 
FastFngrzCommented:
In general, I try to avoid the default "save" buttons (and turn 'em off in the browser version to avoid confusion) - use the Submit action for all saves, just make sure submit can overwrite the same file.
0
 
QPRAuthor Commented:
Does this affect the "created date" in the library?
0
 
FastFngrzCommented:
no, only the modified date - but then again, so would a 'save' command.
0
 
QPRAuthor Commented:
I still don't get why I can only 'save' a form once reopened though and the user is specifically asking for submit once save many
0
 
FastFngrzConnect With a Mentor Commented:
Depending on how you published the form (content type, into a form library, as a plain 'ol XSN on a file server or a document library) will determine the 'save' action.  How are you distributing the form?

Regardless of that, the user should be using the "Submit" function for both saves and submits, even though you can call it "Save" on this view and "Submit" on another view.  

This link helped me through the same type of issue
http://markhaverty.com/sharepoint/custom-save-and-submit-buttons-for-infopath-browser-forms/

Cheers!
0
 
QPRAuthor Commented:
It is saved as an XML in the forms library itself (/Forms/) and is not browser enabled. The clients use IP filler to fill out and submit/save
0
 
FastFngrzCommented:
And the users have contribute permissions on the library, and the submit connection is set to allow overwrite of existing files?

Are you sure all the 'save' buttons are really programmatically doing the submit?
0
 
QPRAuthor Commented:
The users have contribute rights and create them all the time, yes overwriting of existing is enabled.

Programmatically doing the submit?
They are using the save icon on the quick access toolbar. It is a plain vanilla save button that I haven't tied any functionality to.
0
 
CloudedTurtleCommented:
Echoing what FastFngrz has mentioned already; it sounds like you should disable the "Save" button from the menu and only let them "submit" the form.

In IP Filler, clicking the save button will process through a typical "Save As" and ignores all your parameters for file name and location (although your location could be defaulted based on where the form was opened from)
0
 
QPRAuthor Commented:
But if they open an existing form and edit then the save icon works as expected. The submit option is to leave the form open. At this stage it's as though IP doesn't realise it's been submitted despite it showing in the library
0
 
FastFngrzCommented:
Yep!  Kinda drives me nuts too.  Most InfoPath programmers recommend disabling the top ribbon and doing it all programmatically.

If you create a field, set it to the form name, and use that in your submit (or re-submit if they are saving an existing form), then it works whether its a first time save or a re-save.

BUT, the @$%%^@ Save button on the ribbon isn't that smart.  You could de-select the 'Save' option on the ribbon and only allow a submit, but then the user would ALWAYS be able to hit submit, even before the form is ready.  (Most folks like the user to fill out some fields, set some values and THEN submit)
0
 
CloudedTurtleCommented:
When they open an existing form, IP Filler knows where and how to save the form. It already has a name and a location because someone already provided it when it was initially saved/Submitted.

Saving is NOT the same as submitting according to the ribbon buttons. While you can save to a forms library and effectively submit the form, you haven't actually submitted as far as IP is concerned.
0
 
QPRAuthor Commented:
If I haven't submitted then why does the form show in the library with a name.
This is a voucher system and we need sequentially numbered forms. As soon as the user adds a new item (opens a new form) they immediately click submit. This actions looks up the previous id and adds1 to it, prefixes this with a string and adds the form to the library with the new name eg abc987.xml. The form is left open to be filled.
At this stage anyone going to that library can see abc987.xml in the list.
The user then fills out the form and clicks save at which time IP asks save where and what name?
The user must browse to the library and confirm overwrite.
However if the user closed the form straight away, reopened it, filled it out and hit save then IP will update the previously submitted form no questions asked. This is what I'm trying to get to happen without having to resubmit. The submit button is shown as "create voucher" and has submit actions that should only occur once.
0
 
QPRAuthor Commented:
So given that an intiial save (after a submit and form left open) appears to be broken in IP, can I programmatically tell IP on save, look at what you are called/titled, look at where you were submitted to and overwrite the file (like a save function should) and don't ask dumb question? :)
0
 
QPRAuthor Commented:
Thanks that makes it clearer and apologies if this what people have been trying to tell me all along. Still seems strange - I wouldn't expect normal.dot to behave like this. But at least I can go back to the users with a reason
0
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.