[FX.php List] Design for Locked Records?

Wed Jan 6 08:45:59 MST 2010

Wow. That's pretty robust. Nothing technically challenging...just 
planning for potential conflict.

Curious...what determines the level of error trapping and exception 
handling in your client projects?  Do the clients explicitly or 
implicitly request this level of handling?

Clients cover the gamut. Some of my own clients might not notice that 
the web server has been down for 1/2 day, so record locking isn't 
high on their list. ;-)

In my current project, this is the first where FMP users might have 
the possibility to conflict.

Ultimately, I guess the answer is to present the potential issue to 
the client and see if they want to pay for extra programming to 
handle the occasional conflict.

Thanks for the perspective.

Jonathan

>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
>>>>
>>>><mailto:jonathan at exit445.com>jonathan at exit445.com
>>>>
>>>><http://www.exit445.com>http://www.exit445.com
>>>>
>>>>415-370-5011
>>>>
>>>>_______________________________________________
>>>>
>>>>FX.php_List mailing list
>>>>
>>>><mailto:FX.php_List at mail.iviking.org>FX.php_List at mail.iviking.org
>>>>
>>>><http://www.iviking.org/mailman/listinfo/fx.php_list>http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>>--
>>>>
>>>>Jonathan Schwartz
>>>>
>>>>Exit 445 Group
>>>>
>>>><mailto:jonathan at exit445.com>jonathan at exit445.com
>>>>
>>>><http://www.exit445.com>http://www.exit445.com
>>>>
>>>>415-370-5011
>>>>
>>>>_______________________________________________
>>>>
>>>>FX.php_List mailing list
>>>>
>>>><mailto:FX.php_List at mail.iviking.org>FX.php_List at mail.iviking.org
>>>>
>>>><http://www.iviking.org/mailman/listinfo/fx.php_list>http://www.iviking.org/mailman/listinfo/fx.php_list
>>>>
>>>
>>>_______________________________________________
>>>
>>>FX.php_List mailing list
>>>
>>><mailto:FX.php_List at mail.iviking.org>FX.php_List at mail.iviking.org
>>>
>>><http://www.iviking.org/mailman/listinfo/fx.php_list>http://www.iviking.org/mailman/listinfo/fx.php_list
>>>
>>
>>
>>--
>>Jonathan Schwartz
>>Exit 445 Group
>><mailto:jonathan at exit445.com>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
><mailto:steve at matatirosolutions.co.uk>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

-- 
Jonathan Schwartz
Exit 445 Group
jonathan at exit445.com
http://www.exit445.com
415-370-5011
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20100106/223646e0/attachment.html