I've attached a test file which shows multi-user tests on record locking. I've modified it for stand alone by using a new window to signify a different user. The script shows that Get ( RecordOpenState ) can be deceptive in what it produces and I now understand that its purpose is to test the CURRENT user's possession status and not the actual state of the record itself. In script called TEST, it produces a 0 to the current user (in the new window) but shows a 2 to the original window (1 being they are creating new record which isn't yet committed and 2 being they are modifying a record which isn't yet committed). I am posting with two related questions...

Question 1:

FM Help says that [color:green]"If you specify the context for the current calculation, this function will be evaluated based on that context; otherwise, it will be evaluated based on the context of the current window."

I am curious how such a 'context' test might be performed. For instance, I cannot see how checking which window is open, nor the user account would work. In multi-user, many users might have the SAME window open. It might work if it was somehow based upon a different table occurrence but - this particular function is USER-FOCUSED and a many users can have the same context! Does anyone know how FileMaker meant this sentence to be used?

Question 2:

I realize I can test whether a record is locked by testing with Get ( LastError ) such as ...

Set Error Capture [ on ]

Set Field [ text ; blabla ]

Set Variable [ $error ; Get ( LastError ) ]

If [ $error = 301 ]

# Set Field failed; record is locked by someone else

... do whatever for failure

Else

... do whatever for success

End If

But I believe I'd prefer a simpler way and I'm wondering if anyone sees a problem with this 'possess the record' script instead:

Open Record Request

# see if I now own the record. A 0 means someone else must be possessing it.

If [ not Get ( RecordOpenState ) ]

... do whatever for failure such as exit script or halt etc ...

Else

... do whatever for success

... now release the record so others can modify it

Commit Record/Request

End If

This second method seems cleaner because we don't have to Set Error Capture[] nor do we need to send the error to a variable and then test it. It is also much easier to create and remember. If it works well, I will probably begin adding it to ALL my scripts which require changing data in a record. I haven't been able to break it yet but I don't know everything. Input greatly appreciated!

LaRetta

RecordOpen.zip

Edited August 25, 200817 yr by Guest

That's "interesting" - I didn't know Get ( RecordOpenState ) was so limited. Hurray for FMP documentation...

As for your question, I believe it should work (but based on the above, what do I know) - although I see very little difference between:

Open Record Request

If [ not Get ( RecordOpenState ) ]

... do whatever for failure such as exit script or halt etc ...

Else

... do whatever for success

... now release the record so others can modify it

Commit Record/Request

End If

and:

Set Error Capture [ On ]

Open Record Request

If [ Get ( LastError ) = 301 ]

# or just If [ Get ( LastError ) ]

... do whatever for failure such as exit script or halt etc ...

Else

... do whatever for success

... now release the record so others can modify it

Commit Record/Request

End If

I mean, you're going to have error capture turned on anyway, no? If not, your user will see an error message right after the first step. So it comes down to the same number of steps. You only need to store error into a variable if you need it in subsequent steps.

You are certainly right about the scripts being the same. I suppose it just seems easier because that appears to be the only purpose of Get ( RecordOpenState )!

That's "interesting" - I didn't know Get ( RecordOpenState ) was so limited. Hurray for FMP documentation...

If we cannot test for different contexts, then it truly appears to be, not only deceptive, but also a bit worthless. Okay ... so it tells you whether you (via script) are creating a new record and haven't modified it yet or whether you are changing an existing record; or that you haven't opened it yet. But, well, we KNOW THAT since we're the script which is being executed. Doh!

Thank you, Michael!

LaRetta

FM Help says that [color:green]"If you specify the context for the current calculation, this function will be evaluated based on that context; otherwise, it will be evaluated based on the context of the current window."

This bit confuses me too. These are the functions I found that contain the same verbiage:

Get(AccountName)

Get(ExtendedPrivileges)

Get(SortState)

Get(FilePath)

Get(FoundCount)

Get(RecordNumber)

Get(RecordAccess)

Get(UserCount)

Get(PrivilegeSetName)

Get(RecordOpenState)

Thank you for noticing that, DJ. I have no idea how the context can be changed for these functions. I just shake my head ever so slightly and wonder what the FileMaker technical writer was smoking when he wrote the Help section. This is not to say it is without meaning; only that I can't grasp it.

:pounce:

Your

if [ not Get ( RecordOpenState ) ]

Method worked very well for me. Like you, I didn't want to have to test for the error, I wanted to know if it was locked before I submitted the data... worked very well..

In fact, I plugged a loop into it, that if it fails, it will try again, until it is available, then it submits, commits, and exits.

Cheers!