Yes, Bill. I never show a record for entry. I use global fields (cleared by script on opening a new "record"), submit those to a real new record by script, wash-rinse-repeat (clear globals, show form). By their nature a new user session should start with blank global fields, but I kick them first any way.
I do the same think for find. Display is not editable either (only by globals, again). IWP works if you work it well. The same for WD.
I'm definitely reading between the lines of your post to try to make sure that I understand a few of the details of your system, and, honestly, I don't know if I've guessed correctly. I'm going to take a stab I describing it as I understand it.
From your description, it sounds as though the methodology currently in place might be as follows:
1) Someone wants to register.
2) They somehow get to your IWP page to do so.
3) At that page they are supposed to see a blank record waiting for them to fill in.
4) They fill in their data, and then click a button to submit.
5) The submit button triggers a script that does the following:
a) It commits the user's changes to the originally blank record
b) It creates (and commits) a new blank record which will be used by the next registrant who comes along/
The process then repeats with each successive registrant.
Is this an accurate synopsis? If not, perhaps you could flesh out a few more of the details of how your system works?
If I have guessed correctly:
My suggestion would be to perform all set up for each new user (including creating a new blank record) in a script that is triggered on file open (presumably when the new registrant arrives to your site), rather than trying to take care of some of the setup at the end of the previous registration.
I believe that this will help avoid timing and locking issues that could occur in a multi-user scenario where, for example, three new people come to register within the span of one thirty seconds, but each of them takes at least a couple of minutes before they click the submit button.
Another scenario that this might help avoid would be a split-second timing issue whereby a new user comes to the site just as the script that processes the previous user is currently running, and possibly has completed step 5a (mentioned above), but not step 5b.
If I recall correctly, IWP will use up serial numbers and record IDs each time a new record is "created", but it will not actually insert the new record into the table until the IWP user (or script) has committed the new record. Thus, in the case where a new registrant abandons their application without pressing the submit button, the methodology that I propose would result in some gaps in your serial numbers and/or record ID values, but it should not have to result in having random "blank" records in your table.
I hope that perhaps these thoughts helpful to you.
Ver best regards,
Message was edited by: steve_ssh
Edit: I like even better the advice that Beverly gave about using global fields.
Yes, you guessed correctly and provided excellent help.
Great suggestion Beverly.
The extra layer of globals will protect against refresh issues like this.
That solved it.
In case it helps, I'd like to mention a related tidbit concerning IWP, global fields, and a multi-user scenario:
Unlike in the regular FMP client, in IWP when a user enters a global field, it will lock the entire record.
This means that if you are using global fields to gather user input in IWP, you will need to make sure that users that are simultaneously accessing your interface will each be on distinct records as they are entering their data. Otherwise, if two different users wind up on the same record, only one of them will be able to enter data, despite the fact that they are entering data into global fields.
Since this is different from how things work in a FMP client environment, this is often a small gotcha that developers encounter when they first start using global fields in IWP.
Note: The above does not apply when in Find mode, as, in Find mode, the user is not in a state where they are on a record.
Hope this helps & very best,
Thank you Steve.
That's a good thinkg to know!