Whoops

[MEG]

I think I have made a large error as a developer and I need to know if and how I can get around it. I am creating a database for our production line which will be supported by Filemaker Server 5(multiusers). I created a prototype and have come to realize that there will be 3 operators on 1 record at the same time entering their information in different fields and different layouts, but they need to be putting the information on the same record because each operator does a different step of the production process. Filemaker does not allow more than one person entering on 1 record. Is there a way around this?

[LiveOak]

The only answer I can think of is to break the data into three records in the same file or 3 different files. The record locking is pretty fundamental and can't be altered. If you didn't have some sort of locking, what should FM do when on user types a 3 in the same record/field another user is typing 5 into. The design choice made was protect at the record level, rather than the record/field level.

-bd

[Chuck]

Here's a possible solution. Create three separate files, each of which has the fields that one of the people needs to edit. When a user needs to edit the data, the data is first copied over to the appropriate file, either with Set Field steps or with an Import step, and the user edits the data there. There's a button in that file to submit the data and actually save it, and this takes the data back to the real file. You don't actually need to have three separate files, you could do it all with one file. Then the single file would have three separate records, one for each user who could be editing it at the same time.

Chuck

[Kurt Knippel]

quote:

---

Originally posted by Chuck:

Here's a possible solution. Create three separate files, each of which has the fields that one of the people needs to edit. When a user needs to edit the data, the data is first copied over to the appropriate file, either with Set Field steps or with an Import step, and the user edits the data there. There's a button in that file to submit the data and actually save it, and this takes the data back to the real file. You don't actually need to have three separate files, you could do it all with one file. Then the single file would have three separate records, one for each user who could be editing it at the same time.

---

Using global fields can also help accomplish this task, but you need to make judicious use of the Go To Field [] script step with NO (as in ZERO, NADA, NONE, ZIP) parameters. This will help to unlock the record as it cause any field that a user may be clicked into to be exited.