LaRetta Posted August 25, 2008 Posted August 25, 2008 (edited) 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, 2008 by Guest
comment Posted August 25, 2008 Posted August 25, 2008 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.
LaRetta Posted August 25, 2008 Author Posted August 25, 2008 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
David Jondreau Posted August 25, 2008 Posted August 25, 2008 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)
LaRetta Posted August 26, 2008 Author Posted August 26, 2008 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:
ejpvi Posted October 9, 2009 Posted October 9, 2009 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! 1
Recommended Posts
This topic is 5524 days old. Please don't post here. Open a new topic instead.
Create an account or sign in to comment
You need to be a member in order to leave a comment
Create an account
Sign up for a new account in our community. It's easy!
Register a new accountSign in
Already have an account? Sign in here.
Sign In Now