hi.

I

One solution is to add a password field to your register database and through the web security database make the field require an exact match to update the record. You can then allow the users to change the password via scripts.

This way each record requires the user to supply that password to make changes.

quote:

---

You can then allow the users to change the password via scripts.

---

Scripts are not reliable on Web. When new users will trigger script, the running script from previous user is cancelled, or stalled.

WebCompanion can do many transactions per second, but essentially it is Single User application.

IMHO, scripts are OK on web when the functionality of the site is not relying on them.

quote:

---

Originally posted by Anatoli:

When new users will trigger script, the running script from previous user is cancelled, or stalled.

---

Where did you see or how did you determine this?

I have never had this occur (that I am aware of), nor have I seen it in any web event log that I've seen. I was under the impression that an incoming FMP requests from the web are queued and handled in the order received.

I try to avoid scripts on web pages (as Anatoli suggested) but agree with dspires that Web Companion requests are queued. What would happen if a FMP user on the server ran a script, I doono, then it might cancel. I avoid scripts because they complicate things and slow processes down.

Onto the real issue...

You could create a cookie on the person's computer (browser) that has a unique identifier in it. The web page can then display an edit form if the cookie matches the id of the user who created it.

In implementing this system, give thought to also build an admintrative system that lets people acquire the cookie if it gets lost or they change machines etc.