Locking/Opening multiple records

[Matt Klein]

Does anyone know of a way to lock multiple records?

The only way I know of is to open a separate window for each record I want to lock.

I'd love to find out if anyone else has found a more elegant, less intensive method or if I am overlooking something obvious.

[John Mark Osborne]

Can you tell us why you want to do this? Maybe there is an alternative approach where you won't need to lock all those records.

[Matt Klein]

Let's say you have 10 records in a found set and you want to replace the data in a field on each of the records. If any or all of the records in that found set are open/locked by another user or window, those records that are opened/locked will be skipped over if Set Error Capture is set to ON. This is a problem in an All or Nothing situation. In otherwords, if one or more of the records is locked I don't want any changes to be made.

So, in order to Pre-check the open/locked status of the records in the found set, I can loop through the records setting a field to itself as I loop through the records and trapping to see if any of the records are open/locked. If at any point in the loop I hit a record that is open/locked I can stop the loop and inform the user. That's all well and good.

That brings me to my post...let's say I run the loop as described above and find no open/locked records during the process of running the loop. As a result, I go ahead and do the replace, but between the time I looped through the records and the time I run the replace a user opens/locks one of the records in the found set. Just what I was trying to avoid.

I could replace the data in the field as I go through the initial "Check" loop, but then what if I hit a open/locked record in the middle of the loop? How do I restore the previous records to their original states? I can think of ways to do it, but none are particularly attractive to me.

What I really want to do is open/lock the records as I am looping through them in the "Check" loop releasing them either after finishing the replace or if I hit a record that is open/locked during the "Check" loop.

[comment]

I don't quite see what opening windows has to do with locking records. Not to mention that if each record is locked in its own window, then no single window can run Replace succesfully.

I would try something like:

Set Error Capture [ On ]

Go to Record/Request/Page [ First ]

Loop

Open Record/Request

If [ Get ( LastError ) ]

Commit Records/Requests

Show Custom Dialog [ "Try later"]

Exit Script

End If

Go to Record/Request/Page [ Next; Exit after last ]

End Loop

Replace Field Contents [ Table::Field; "Value" ) ] [ No dialog ]

Show Custom Dialog [ "Success"]

[Matt Klein]

Let's say you run the loop in your example and it makes it through all the records without returning an error.

How would you address the possibility of a user locking a record, that was not locked when checked in the loop, before or during the performance of the Replace Field Contents step?

[comment]

You have a point there. I wouldn't go this route anyway: I would probably just loop repeatedly thru the records, trying to modify them, until I got them all.

But if it's that critical that all should be modified at the same time, consider doing a similar script in a portal - where going to the next row will NOT release the child.

[Matt Klein]

The portal method is a GREAT new feature in FileMaker Pro and actually addresses the locking issue that I have in that you can loop through the portal rows replacing the data as you go and then if you hit one that is locked you can use the Revert Record/Request script step and it restores all the records in the portal to their original state.

The gotcha here is that it will only work if the records are related records.

I am looking for a way to actually mimic the portal behavior above without using a portal.

[comment]

Turning a found set into a related set is rather trivial, especially with 8A and a small set.

BTW, it may a great feature for your current problem, but the opportunity for a single user to lock a large number of records is quite alarming.