7 Replies Latest reply on Apr 20, 2014 11:25 AM by BillMiller

    IWP Browser Refresh Issue


      I have a client with an IWP registration page.

      For some people who access this page on their browser, they will see the last person's registration info.

      But FM has been set to do an immediate new record and commit once someone hits the submit button, so previous data would not display.


      And we have done a complete cache clear, history reset, turn off the browser and restart and the data will still appear.

      I don't see it on my browser, but the client says he and a couple of others have seen previous registration data.


      It almost seems like there is a cache on the hosting site which is restoring old data, because we have done everything we can do have both FM and the browser clear and refresh.


      Any suggestions?

        • 1. Re: IWP Browser Refresh Issue

          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.

          • 2. Re: IWP Browser Refresh Issue

            Hello Bill,


            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.



            Additional Note:


            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.

            • 3. Re: IWP Browser Refresh Issue

              Thank you.

              Yes, you guessed correctly and provided excellent help.


              • 4. Re: IWP Browser Refresh Issue

                Great suggestion Beverly.

                The extra layer of globals will protect against refresh issues like this.

                Will implement.


                • 5. Re: IWP Browser Refresh Issue

                  That solved it.

                  Thanks guys!

                  • 6. Re: IWP Browser Refresh Issue

                    Hi Bill,


                    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,



                    • 7. Re: IWP Browser Refresh Issue

                      Thank you Steve.

                      That's a good thinkg to know!