[FX.php List] Design for Locked Records?
Steve Winter
steve at bluecrocodile.co.nz
Wed Jan 6 10:16:58 MST 2010
Hi Dale,
Well actually, I was kind of modifying what I actually do to make it
more specific to Jonathan's request...
Because I have to do the 'log every change' thing, I actually do all
the checking on every submit, so that I know who does what, which as
you say does account for other web-based or FM client changes as well
as the record being currently locked...
Your mentioning checking the modID is something which I hadn't
considered and in 99% of cases would save me a 'round' of checks,
since if I recorded the modID of my original data I could do a simple
check of the current modID at submission time... if it's still the
same, then I only have to do a compare of submitted with original...
Something for next time ;)
Cheers
Steve
Sent from my iPhone
On 6 Jan 2010, at 15:17, Dale Bengston <dbengston at tds.net> wrote:
> Steve,
>
> More interesting than collisions with FMP client users, couldn't
> this also be adapted to avoid collisions with other web users? You'd
> have to re-query rather than trapping for a 301 error. Now that I
> think about it, trapping a 301 error doesn't defend against changes
> committed since a web user loaded a record into their browser; it
> just traps changes in process. Hmmm. I guess looking at the modID
> would cover that.
>
> Dale
>
> On Jan 6, 2010, at 2:07 AM, Steve Winter wrote:
>
>> Hi Jonathan,
>>
>> In many of my solutions I'm just ignoring it, as there are seldom
>> (if ever) FM client users of most of the systems I've developed.
>>
>> In one solution I've done recently I did have to track it, and I
>> also needed to report on every change that a web user was making in
>> a 'logging' table, so here's what I did;
>>
>> When the web form is loaded it put all of the current values into a
>> session variable, so I know the state of the database at the moment
>> when the web user loaded the page.
>>
>> When the form is submitted, I trap for a 301. If I receive a 301 I
>> then stick the current values which the web user has submitted into
>> a second session variable. Next I retrieve the current values from
>> the database. So I now have three sets of data;
>>
>> - original
>> - web users desired content
>> - db current
>>
>> I then do a comparison, field by field, of each of the fields.
>>
>> First I compare what the web user is submitting, with what's
>> currently in the db. If they are the same, then there's no problem,
>> can just submit that value.
>>
>> If they are different, then I do a second comparison between what
>> was originally in the database, and what is in the database now. By
>> doing this I can tell if the FM Client user has changed things. If
>> these values are the same, then I know that the FM client user has
>> not changed the field, but the web user has, so it's fine to submit
>> that data too.
>>
>> The final check if the original and the current are different, is I
>> then need to compare what the web user was submitting, with what is
>> in there now (i.e what the FM client user did). If they are the
>> same, no problem, can just submit what the web user was doing,
>> since both users have made the same change [this really only works
>> with single select or radio buttons, rarely with text entry or
>> checkboxes]
>>
>> Now I'm left with a (hopefully small) set of cases where both the
>> FM client user, and the Web user have tried to make changes to the
>> same field, but have set different values.
>>
>> If there were no collisions, I now also know which fields the web
>> user was changing, from what, and to what, so can stick those
>> changes into my logging table...
>>
>> At this point, I display the original form back to the web user. I
>> put an error at the top of the page saying 'Another user has
>> modified this record since you began editing it. Please review the
>> errors below'. In the fields where there were no problems, I simply
>> put the submitted data back into the field (so if they were
>> unchanged, only changed by the web user, or changed by both, but to
>> the same thing).
>>
>> Where the 'collisions' occurred, I put what is currently in the
>> database into the field/select/checkbox/radiobutton, then display a
>> text message with the values which the web user had posted beside
>> it. In this way they can see what's in the db now, plus what they
>> were putting in, and amend the new values as required.
>>
>> Because this system is all in a 'closed' solution I can't give you
>> access to it, but if you get really stuck then I could probably rip
>> some code out an knock up a demo quickly enough...
>>
>> Hope this helps...
>>
>> Cheers
>> Steve
>>
>> On 6 Jan 2010, at 00:40, Jonathan Schwartz wrote:
>>
>>> Hi Dale,
>>>
>>> Thanks for the response. I assume that 301 would be the error.
>>>
>>> If the FMP user left the cursor in the field and went to lunch or
>>> even went home for the day, it would be a long wait.
>>>
>>> Wondering if anyone is dealing with this, or, just ignoring it.
>>>
>>> J
>>>
>>> At 6:22 PM -0600 1/5/10, Dale Bengston wrote:
>>>> Jonathan,
>>>>
>>>> Happy new year!
>>>>
>>>> What type of response do you get from FX if you try to modify a
>>>> locked record? Do you get error 301 "Record is in use by another
>>>> user"? Maybe you could trap for that and manage the expectations
>>>> of your web users that they may need to try again later.
>>>>
>>>> Dale
>>>>
>>>> On Jan 5, 2010, at 5:55 PM, Jonathan Schwartz wrote:
>>>>
>>>>> Any takers?
>>>>>
>>>>> I'm developing a solution where the client employees are
>>>>> interacting with the same db that the online system uses. It is
>>>>> possible that an office worker might be "in" a record while the
>>>>> online customer is trying to update.
>>>>>
>>>>> What to do?
>>>>>
>>>>> Error out?
>>>>> Try again?
>>>>> Send a message to the office worker? (possible?)
>>>>> Save the data to another file?
>>>>>
>>>>> Just looking for ideas.
>>>>>
>>>>> J
>>>>>
>>>>>
>>>>> Happy New Year Folks,
>>>>>
>>>>> Does anyone design for the instance where an fx.php transaction
>>>>> tries to update a record that is being used by a native
>>>>> FileMaker user, and thus is locked?
>>>>>
>>>>> If so, how do you handle?
>>>>>
>>>>> Thanks
>>>>>
>>>>> J
>>>>> --
>>>>> Jonathan Schwartz
>>>>> Exit 445 Group
>>>>> jonathan at exit445.com
>>>>> http://www.exit445.com
>>>>> 415-370-5011
>>>>> _______________________________________________
>>>>> FX.php_List mailing list
>>>>> FX.php_List at mail.iviking.org
>>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>> --
>>>>> Jonathan Schwartz
>>>>> Exit 445 Group
>>>>> jonathan at exit445.com
>>>>> http://www.exit445.com
>>>>> 415-370-5011
>>>>> _______________________________________________
>>>>> FX.php_List mailing list
>>>>> FX.php_List at mail.iviking.org
>>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>> _______________________________________________
>>>> FX.php_List mailing list
>>>> FX.php_List at mail.iviking.org
>>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>>
>>> --
>>> Jonathan Schwartz
>>> Exit 445 Group
>>> jonathan at exit445.com
>>> http://www.exit445.com
>>> 415-370-5011
>>> _______________________________________________
>>> FX.php_List mailing list
>>> FX.php_List at mail.iviking.org
>>> http://www.iviking.org/mailman/listinfo/fx.php_list
>>
>> Steve Winter
>> steve at bluecrocodile.co.nz
>> m: +44 77 7852 4776
>> 3 Calshot Court, Channel Way
>> Ocean Village, Southampton SO14 3GR
>>
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
>
> _______________________________________________
> FX.php_List mailing list
> FX.php_List at mail.iviking.org
> http://www.iviking.org/mailman/listinfo/fx.php_list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20100106/0a0b9c1d/attachment-0001.html
More information about the FX.php_List
mailing list