[FX.php List] Design for Locked Records?

Wed Jan 6 10:19:54 MST 2010

Yip, as you say nothing too complex...

In terms of how far I go, depends on the solution, the client and the  
security... If it's anything which invovlea taking money off people,  
then it's for to be bulletproof!

I've got a pretty basic set of things that I do in every solution that  
I develop to trap for the key issues, then as you say, will enhance to  
suit the needs/budget of the individual client...

Cheers
Steve

Sent from my iPhone

On 6 Jan 2010, at 15:45, Jonathan Schwartz <jschwartz at exit445.com>  
wrote:

> 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
>>>>
>>>>> 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
>
>
> -- 
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://mail.iviking.org/pipermail/fx.php_list/attachments/20100106/598b9d4d/attachment.html