IWP using an existing record

[doubleclicker]

I'm just wondering if anyone has come across a problem with IWP (FM11/Win) and using existing records?

I have a database hosted with automatic login as Guest (read/write) via a Browser. There are no tools available on screen, all is navigated via buttons. A user creates a new record with a button that simply creates a new record and takes the user to the data entry screen for them to fill out the details. My problem is that on a couple of occasions the online user is presented with someone else's record, not a new record. Does anyone have a suggestion as to how this can happen?

[Agnes Riley]

The best solution is to not use IWP. I have not found that it guarantees results.

[brian rich]

Hi doubleclicker

Does your 'New record' script commit the record before you allow the user to start editing it?

Because of the web interface, I always try to commit a new record as soon as it is created; it seems to work more reliably that way -

FWIW, I build IWP interfaces using a read-only view and an edit view. The actual record is displayed in the read-only view, but the fields are not editable. To edit the record, the user clicks a button that loads an edit view screen, where the field values are loaded into corresponding global variables, which the user edits. To save the edit informatiom, the user clicks a save button on the edit view which then writes the global values into the database. This dual layout structure takes somewhat longer to design and build, but has the advantage that you know that all the user edits are committed at once, and you can manage your own validation too. You may need to add your own record locking flag if users are likely to try and edit the same record, but with this dual layout structure, it is easy to test for a record in use before editing, lock it when editing and release it on saving.

I've been running an FMP10 Server supporting an IWP database for more that 3 years, and it works just fine - zero maintenance required. It is a lightly used site that could not justify the CWP approach in terms of development time, and didn't require anything that could not be managed using IWP.

HTH

Brian