[FX.php List] Design for Locked Records?

Dale Bengston dbengston at tds.net
Wed Jan 6 08:17:59 MST 2010 

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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20100106/0f2b298d/attachment-0001.html

More information about the FX.php_List mailing list