Modify record in use

[jasonwood]

I was just wondering... could a script modify a field in a record even if someone else on the network is "using" that record?

I am anticipating a problem with adjusting inventory of a product if somebody is looking up that product elsewhere.

If my assumption is correct.... any suggestions on how to get around this problem?

Thanks!

[BobWeaver]

A script cannot modify a record that's in use by another user, but the script can detect the problem, and take appropriate action such as pausing and waiting until the record is free. You could add the following lines to your script to avoid problems:

code:

---

#assuming you are in the record that you want to modify.

Loop

Go to field[someField]

# Entering a field in a locked record will generate error 301

Exit Loop If [status(CurrentError)<> 301]

Pause [5 seconds]

End Loop

# Now continue with your record modifications

[cinolas]

I agree that this is the way to go...

However, what if someone left for lunch (or for the day!) leaving the cursor in a field ? The record wont be freed, the script will just go on forever !

For this reason, as suggested by someone in FileMaker Advisor, it is useful to try for a number of times then ask the user who ran the script what to do with the situation.

The ideal way of dealing with such a situation would be to first ask the user to release the record (anyone knows how to send a message to a specific user ? without the admin functions ?) then after a given time disconnect the user (again I'm looking for a way to do this without the use of the admin functions).

The way I'm dealing with this right now :

If the record is busy (error 301) I wait 5 seconds then try again, for about 2 minutes. Then the script asks the user who ran the script if he wants to keep on trying (for another 2 minutes) or Abort the script. If the script is aborted, the clean-up script is triggered (to undo what the previous script had done before being aborted).

Now that's where I'm stuck. Undoing whatever the script had done requires to edit the records that were previously edited successfully... So what if another user went to one of those record entered a field and left for the day ? I agree that the chances of that happening are slim but in the case of my script, if such a situation was not handled my employer could lose money or get sued... So the clean-up script has a similar error catching loop but this one does not allow the user to abort (obviously) and therefore could go on for a long time !

Suggstions are greatly appreciated !

[Kurt Knippel]

You will need to "lock" those records and this is gonna make for some pretty complex navigation. Basically when you start this process you need to step through all the records that you need to work with and mark them as "locked". Once your process is finished you will "unlock" them.

Then your normal navigation must check for the "unlocked" status and if a record is unlocked then it will allow a user to edit the record, first locking it for them, and unlocking it when they are finished.

This way if a user has locked some record you will have to wait for them to unlock it, and if you have locked a record it will prevent another user from locking it until you are done with it.

I actually had to implement this for a client, where we had to step through a process that affected 100s of records across a dozen databases, and if even 1 record was not available we could not commit changes to any of the records. So we first stepped through all of the records we needed, pausing briefly if any were locked, and once we got to the last record we then committed the various changes, and finally unlocked the records.

[Keith M. Davie]

The problem being discussed is one in a multi-user environment. ScriptMaker is single-threaded.

Capt Kurt states that he handled this situation such that, "So we first stepped through all of the records we needed, pausing briefly if any were locked..."

But this is occurring in a multi-user environment. When ScriptMaker is paused, another scirpt can be run. This would then interfere with the paused event. Therefore there must be more to the solution than has been revealed.

[LiveOak]

In real inventory control systems, you never modify a net inventory quantity. You post a transaction to a transaction file that contains the change in inventory and the transaction type (inventory draw, restock, receiving action, etc.).

Any locking approach which directly modifies an Inventory Quantity field allows the possibility of hanging the process. With transactions the only danger is over drawing the inventory with two uses simultaneously posting a draw. With proper scripting it should be possible to create a critical region in the script to prevent over drawing inventory.

-bd

[Rigsby]

Hi! I don

[Kurt Knippel]

But this is occurring in a multi-user environment. When ScriptMaker is paused, another scirpt can be run. This would then interfere with the paused event. Therefore there must be more to the solution than has been revealed.

The way the entire process was handled did not allow for any user to run another script, and the total pauses were for like 2 seconds. Additionally no changes were made unless EVERY needed record was locked by the procedure. If any record was unavailable or the script was broken somehow, nothing had been changed anyway.