Handeling record locks

[Drew Sanderson]

How do you handle record locks in your scripts?

My issue with ErrorCapture ( ON ) is that the user cannot see who has the record locked unlike the default FileMaker error popup. I am not aware of a function that captures this. Leaving it off allows the user to create chaos. I know I could check ahead of time with Get(RecordOpenState) to prevent the chaos but it still won't tell the user who has it locked.

So....

What do you do?

[bcooney]

I simply throw a dialog, "The Record is in Use." If only we could capture that name!

[lance123]

and boot them!

PS This is a really big issue the more complex your systems become. It requires some real thought an planning. Usually for me it has been after the fact. Ie when I run into problems.

Regards,

Lance

[Drew Sanderson]

I simply throw a dialog, "The Record is in Use." If only we could capture that name!

That is what I do too. Just making sure I was not missing something.

I do a lot of posting instead of unstored calcs so it is key to check the record lock and the commit

[LaRetta]

It has been a long-standing dream

http://fmforums.com/...__1#entry301438

[haensz]

I have a couple spots where there are issues like this but it IS important to know who's in there. Let's say the process of invoicing customers. For unrelated reasons, we can only allow one person to invoice at a time.

I first take them to a bogus table, with one record with fields like "Invoicing_InUse" and "Invoicing_User", and set the fields to "1" and "Jane Doe" respectively as the user begins the invoicing process. Then whatever the last button or script in the invoicing process is, I would clear out those Bogus::Invoicing_InUse and Bogus::Invoicing_User fields.

That way if a 2nd person comes in mid-stream, I first check to see if Bogus::Invoicing_InUse = 1. If so, I can tell them that it's in use by "Jane Doe" because it checked to see if Bogus table had a "0" or a "1" value for "Invoicing_InUse" and drop them back off to wherever they were before trying to invoice.

Obviously it's only worth this extra hassle if it's an important process. Or if Jane Doe has a habit of leaving for lunch while in the middle of that process, locking it for all others...

[haensz]

Similar item for my wish list would be to know if a related record is in use. Basic example -- you've got two tables: order and order_lines. A sales rep is changing something on the line item of an order (so they're locking up a record in order_lines).

I don't want another use to try to process that record on the order table -- even though that order record is not in use, it's line items are being changed which could result in a mess for me to clean up...

[bcooney]

You'd like the video about transactional scripting by Todd Geist.

[haensz]

That's a great video.

Holy cow! I did not now that reverting the parent record also reverts the portal records you were about to modify as well. Embarrassing, but maybe that's why you're actually supposed to read some of those manuals instead of just diving in, huh?

[dansmith65]

I almost never run a script with ErrorCapture[ ON ]; I usually turn it on/off for specific sections of the script (like the perform find step). I'm not sure the scenario you are referring to, but a typical scenario where I test for a locked record is when selecting a Customer for an Invoice. In this case, I usually select the customer via a new window, so before opening that new window I open the Invoice record then test for an error; if there was an error, then I exit the script (ErrorCapture was off, so the default FileMaker dialog was shown to the user).

Open Record/Request

If [Get( LastError ) <> 0]

	Exit Script

End If

[haensz]

Dansmith65 --

My typical use for ErrorCapture is to handle find requests. If a user attempts a search that brings up no found records, I prefer to literally show them an empty list rather than loop them back into another search attempt. Seems odd I know, but a lot of my users were getting frustrated when search attempts would "stick them in an endless loop"...

Anyone here in the forum would know that if they'd quit messing up their search request in the first place then it would be able to retrieve some records for them !!!

But it's probably just something I was taught to use early on and it just always stuck (whether I really need to be using it or not).