Re: Record locking & scripted replace (Danny Mack)

classic Classic list List threaded Threaded
15 messages Options
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Linda Trent
Thanks people!

All these ideas are great and the looping was what I started with but the potential for thousands of records and a key user with very slow and unreliable remote access has changed the requirement…this is why it’s all or nothing now. Danny’s suggestion re the global field containing the ID’s may be the cleanest solution and will comply with the business rules, that is, all or nothing.

Danny, if you can point me in the direction of the custom functions that are already available, that would be great, thanks.

Cheers
Linda
_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Richard DeShong
Hi Linda,

I would caution that if you go with the global field containing ID's
method (global-key-portal):

When your process runs on the user's client, and the master record is
locked, the user's FM client has to get a lock on all of the detail
records (potentially thousands).  If the network connection holds, then
your process has to update all detail records in the portal - which is
drastically slower than the blank-utility-layout method.  You said the
user has a "very slow and unreliable" connection.

I would note:

Most business processes would want "all records" to be updated, not just
most.  If this business rule says that they all have to be updated *all
at the same time*, then you need to use the global-key-portal method.  
Just keep in mind that this will lock all of those detail records until
the process is done.  I get the allure of the global-key-portal, as you
know ahead of time that you have a lock on all records.  It is very
"clean".  But this method is typically used for scopes such as a Sales
Order, or a small subset of orders and their detail records.

Since the user has a slow/unreliable connection, no matter which method
you use - please consider using Perform Script on Server. This will
start a "client" on the server and run your script - much more reliable
(and way faster).


On 4/25/2017 2:54 PM, Linda Trent wrote:

> Thanks people!
>
> All these ideas are great and the looping was what I started with but the potential for thousands of records and a key user with very slow and unreliable remote access has changed the requirement…this is why it’s all or nothing now. Danny’s suggestion re the global field containing the ID’s may be the cleanest solution and will comply with the business rules, that is, all or nothing.
>
> Danny, if you can point me in the direction of the custom functions that are already available, that would be great, thanks.
>
> Cheers
> Linda
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Jonathan Fletcher-2
+1


> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>
> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).



--
Jonathan Fletcher
[hidden email]

Kentuckiana FileMaker Developers Group
Next Meeting: 4/25/17

Sent from a device not known for spontaneous combustion

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

wrwaugh
+2

Riley Waugh
[hidden email]




> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>
> +1
>
>
>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>
>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>
>
>
> --
> Jonathan Fletcher
> [hidden email]
>
> Kentuckiana FileMaker Developers Group
> Next Meeting: 4/25/17
>
> Sent from a device not known for spontaneous combustion
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Stephen Wonfor-3
Hi

What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?

Stephen

---

"Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut

> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>
> +2
>
> Riley Waugh
> [hidden email]
>
>
>
>
>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>
>> +1
>>
>>
>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>
>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>
>>
>>
>> --
>> Jonathan Fletcher
>> [hidden email]
>>
>> Kentuckiana FileMaker Developers Group
>> Next Meeting: 4/25/17
>>
>> Sent from a device not known for spontaneous combustion
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

wrwaugh
PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.

Of course the same goes for a script triggered by schedule on the server.  

Riley Waugh
[hidden email]




> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>
> Hi
>
> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>
> Stephen
>
> ---
>
> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>
>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>
>> +2
>>
>> Riley Waugh
>> [hidden email]
>>
>>
>>
>>
>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>
>>> +1
>>>
>>>
>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>
>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>
>>>
>>>
>>> --
>>> Jonathan Fletcher
>>> [hidden email]
>>>
>>> Kentuckiana FileMaker Developers Group
>>> Next Meeting: 4/25/17
>>>
>>> Sent from a device not known for spontaneous combustion
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Stephen Wonfor-3
Riley

Thanks for the info.  Next thing - I learned recently that I can kill a runaway server script by disconnecting that “user” - the server routine that is going on forever.  Same thing for PSOS?

Stephen

---

"It's like someone took a transcript of a couple arguing at IKEA and made random edits until it compiled without errors." ~XKCD#1513

> On Apr 25, 2017, at 9:15 PM, Riley Waugh <[hidden email]> wrote:
>
> PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.
>
> Of course the same goes for a script triggered by schedule on the server.  
>
> Riley Waugh
> [hidden email]
>
>
>
>
>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>>
>> Hi
>>
>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>
>> Stephen
>>
>> ---
>>
>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>
>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>>
>>> +2
>>>
>>> Riley Waugh
>>> [hidden email]
>>>
>>>
>>>
>>>
>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>
>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Fletcher
>>>> [hidden email]
>>>>
>>>> Kentuckiana FileMaker Developers Group
>>>> Next Meeting: 4/25/17
>>>>
>>>> Sent from a device not known for spontaneous combustion
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

wrwaugh
In reply to this post by wrwaugh
And another thought on PSOS.  For those not familiar with PSOS, remember that the server has no point of reference.  It does not know what table you are in.  The script you are  running must tel the server this by including a go to layout script step or whatever is needed to assure that subsequent script steps are relationally correct.

Riley Waugh
[hidden email]




> On Apr 25, 2017, at 11:15 PM, Riley Waugh <[hidden email]> wrote:
>
> PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.
>
> Of course the same goes for a script triggered by schedule on the server.  
>
> Riley Waugh
> [hidden email] <mailto:[hidden email]>
>
>
>
>
>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Hi
>>
>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>
>> Stephen
>>
>> ---
>>
>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>
>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> +2
>>>
>>> Riley Waugh
>>> [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>
>>>
>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>
>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Fletcher
>>>> [hidden email]
>>>>
>>>> Kentuckiana FileMaker Developers Group
>>>> Next Meeting: 4/25/17
>>>>
>>>> Sent from a device not known for spontaneous combustion
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email] <mailto:[hidden email]>
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

wrwaugh
In reply to this post by wrwaugh
Stephen,  I really am not sure but I believe that you are correct that you can use the FMS Admin Console to disconnect the offending user and there by kill the script… not positive though.  I suppose I should Google that.

Riley Waugh
[hidden email]




> On Apr 25, 2017, at 11:15 PM, Riley Waugh <[hidden email]> wrote:
>
> PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.
>
> Of course the same goes for a script triggered by schedule on the server.  
>
> Riley Waugh
> [hidden email] <mailto:[hidden email]>
>
>
>
>
>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email] <mailto:[hidden email]>> wrote:
>>
>> Hi
>>
>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>
>> Stephen
>>
>> ---
>>
>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>
>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> +2
>>>
>>> Riley Waugh
>>> [hidden email] <mailto:[hidden email]>
>>>
>>>
>>>
>>>
>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>
>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Fletcher
>>>> [hidden email]
>>>>
>>>> Kentuckiana FileMaker Developers Group
>>>> Next Meeting: 4/25/17
>>>>
>>>> Sent from a device not known for spontaneous combustion
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email] <mailto:[hidden email]>
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Stephen Wonfor-3
Riley

The disconnect user does work from the Admin console - I’m pretty sure the user is the “schedule name”.

Stephen

----------

"The physicist's greatest tool is his wastebasket."    — Albert Einstein

> On Apr 25, 2017, at 9:20 PM, Riley Waugh <[hidden email]> wrote:
>
> Stephen,  I really am not sure but I believe that you are correct that you can use the FMS Admin Console to disconnect the offending user and there by kill the script… not positive though.  I suppose I should Google that.
>
> Riley Waugh
> [hidden email]
>
>
>
>
>> On Apr 25, 2017, at 11:15 PM, Riley Waugh <[hidden email]> wrote:
>>
>> PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.
>>
>> Of course the same goes for a script triggered by schedule on the server.  
>>
>> Riley Waugh
>> [hidden email] <mailto:[hidden email]>
>>
>>
>>
>>
>>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email] <mailto:[hidden email]>> wrote:
>>>
>>> Hi
>>>
>>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>>
>>> Stephen
>>>
>>> ---
>>>
>>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>>
>>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email] <mailto:[hidden email]>> wrote:
>>>>
>>>> +2
>>>>
>>>> Riley Waugh
>>>> [hidden email] <mailto:[hidden email]>
>>>>
>>>>
>>>>
>>>>
>>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>>
>>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jonathan Fletcher
>>>>> [hidden email]
>>>>>
>>>>> Kentuckiana FileMaker Developers Group
>>>>> Next Meeting: 4/25/17
>>>>>
>>>>> Sent from a device not known for spontaneous combustion
>>>>>
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email] <mailto:[hidden email]>
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

wrwaugh
In reply to this post by Stephen Wonfor-3
An anecdote about PSOS and throughly testing you script.  I recently ran a script that found a set of records then deleted the found set.  I failed to  test for a successful find, and due to finding in the wrong related Table Occurrence, no records were found. The script then deleted the then current set of all 5,700,000 records.  A painful but memorable mistake.

Riley Waugh
[hidden email]




> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>
> Hi
>
> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>
> Stephen
>
> ---
>
> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>
>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>
>> +2
>>
>> Riley Waugh
>> [hidden email]
>>
>>
>>
>>
>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>
>>> +1
>>>
>>>
>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>
>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>
>>>
>>>
>>> --
>>> Jonathan Fletcher
>>> [hidden email]
>>>
>>> Kentuckiana FileMaker Developers Group
>>> Next Meeting: 4/25/17
>>>
>>> Sent from a device not known for spontaneous combustion
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Jonathan Fletcher-2
In reply to this post by wrwaugh
PSoS is very powerful. It can save you a boatload of network traffic if your connection is, um, less than optimal.

Create PSoS scripts to have a switch. They shouldn’t run if the file isn’t hosted or if some other condition is met, like a key combination or a global variable you set manually. That way it can debugged locally to make sure that it runs cleanly. Then when you run it on the server you can also check the server logs to see what kind of errors it generates.

Also:
. Be careful that anything that gets sent to the server is a server compatible script step.
. Remember to plan around any window or layout script triggers that will run.
. Do lots of error capture.
. Either return your errors to the calling script, or log them in a table that you can pull up in your solution.

Just some tips.

Jonathan


> On Apr 25, 2017, at 11:15 PM, Riley Waugh <[hidden email]> wrote:
>
> PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.
>
> Of course the same goes for a script triggered by schedule on the server.  
>
> Riley Waugh
> [hidden email]
>
>
>
>
>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>>
>> Hi
>>
>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>
>> Stephen
>>
>> ---
>>
>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>
>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>>
>>> +2
>>>
>>> Riley Waugh
>>> [hidden email]
>>>
>>>
>>>
>>>
>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>
>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Fletcher
>>>> [hidden email]
>>>>
>>>> Kentuckiana FileMaker Developers Group
>>>> Next Meeting: 4/25/17
>>>>
>>>> Sent from a device not known for spontaneous combustion
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Jonathan Fletcher
[hidden email]

Kentuckiana FileMaker Developers Group
Next Meeting: 4/25/17

Sent from a device not known for spontaneous combustion

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Stephen Wonfor-3
In reply to this post by wrwaugh
Riley

Reminds me of the 40,000+ eMails I had our server send to 8 internal eMail addresses.  Surely the default behaviour for GoToNextRecord should be “Exit After Last”.   Which brings up script steps like “Enter Find Mode [pause]”.   25 years of doing this and I think I am at once for GoToNextRecord not exiting after last and 0 for Enter Find Mode then pausing.  I also always would want table mode to include a header by default.
And since Johnno has mention the server logs - would it not be nice if the server did not report “Script Errors” on things like getting to the last record in a loop or a Find that came up with no results?  We almost need a script step for “Suppress Obvious Errors” - that would not fail on the last record in a loop but rather would fail on an actual error - setting a field in the wrong context, going to wrong layout etc.  

Stephen

---

1 Pound honey = 2,000,000 Bee round-trips.

> On Apr 25, 2017, at 9:28 PM, Riley Waugh <[hidden email]> wrote:
>
> An anecdote about PSOS and throughly testing you script.  I recently ran a script that found a set of records then deleted the found set.  I failed to  test for a successful find, and due to finding in the wrong related Table Occurrence, no records were found. The script then deleted the then current set of all 5,700,000 records.  A painful but memorable mistake.
>
> Riley Waugh
> [hidden email]
>
>
>
>
>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>>
>> Hi
>>
>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>
>> Stephen
>>
>> ---
>>
>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>
>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>>
>>> +2
>>>
>>> Riley Waugh
>>> [hidden email]
>>>
>>>
>>>
>>>
>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>
>>>> +1
>>>>
>>>>
>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>
>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>
>>>>
>>>>
>>>> --
>>>> Jonathan Fletcher
>>>> [hidden email]
>>>>
>>>> Kentuckiana FileMaker Developers Group
>>>> Next Meeting: 4/25/17
>>>>
>>>> Sent from a device not known for spontaneous combustion
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Jonathan Fletcher-2
Riley, so true!

I agree that the default choices in many places in our beloved development platform are not those of a regular developer, but of some engineers who work in a weird-shaped building and don’t actually have to use their product on a daily basis.

I saw a presentation at Pause New York years ago, where the presenter (can’t remember who it was) had the BRILLIANT idea of having FileMaker remember your choices so that if you chose something 3 times in a row it would make THAT your default. Think how many clicks that would save you!

Jonathan


> On Apr 25, 2017, at 11:42 PM, Stephen Wonfor <[hidden email]> wrote:
>
> Riley
>
> Reminds me of the 40,000+ eMails I had our server send to 8 internal eMail addresses.  Surely the default behaviour for GoToNextRecord should be “Exit After Last”.   Which brings up script steps like “Enter Find Mode [pause]”.   25 years of doing this and I think I am at once for GoToNextRecord not exiting after last and 0 for Enter Find Mode then pausing.  I also always would want table mode to include a header by default.
> And since Johnno has mention the server logs - would it not be nice if the server did not report “Script Errors” on things like getting to the last record in a loop or a Find that came up with no results?  We almost need a script step for “Suppress Obvious Errors” - that would not fail on the last record in a loop but rather would fail on an actual error - setting a field in the wrong context, going to wrong layout etc.  
>
> Stephen
>
> ---
>
> 1 Pound honey = 2,000,000 Bee round-trips.
>
>> On Apr 25, 2017, at 9:28 PM, Riley Waugh <[hidden email]> wrote:
>>
>> An anecdote about PSOS and throughly testing you script.  I recently ran a script that found a set of records then deleted the found set.  I failed to  test for a successful find, and due to finding in the wrong related Table Occurrence, no records were found. The script then deleted the then current set of all 5,700,000 records.  A painful but memorable mistake.
>>
>> Riley Waugh
>> [hidden email]
>>
>>
>>
>>
>>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>>
>>> Stephen
>>>
>>> ---
>>>
>>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>>
>>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>>>
>>>> +2
>>>>
>>>> Riley Waugh
>>>> [hidden email]
>>>>
>>>>
>>>>
>>>>
>>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>>
>>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> Jonathan Fletcher
>>>>> [hidden email]
>>>>>
>>>>> Kentuckiana FileMaker Developers Group
>>>>> Next Meeting: 4/25/17
>>>>>
>>>>> Sent from a device not known for spontaneous combustion
>>>>>
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>>
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Jonathan Fletcher
[hidden email]

Kentuckiana FileMaker Developers Group
Next Meeting: 4/25/17

Sent from a device not known for spontaneous combustion

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
Reply | Threaded
Open this post in threaded view
|

Re: Record locking & scripted replace (Danny Mack)

Richard DeShong
In reply to this post by Jonathan Fletcher-2
And for those that don't want to design their script with the added
complexities of running it on the server (on a schedule or using PSoS),
using the blank-layout method achieves very speedy results - nearly as
fast as PSoS.  And for those processes where the user has to wait a
while, you can use a blank layout with a Header a very short Body part
to achieve a kind-of progress bar.


On 4/25/2017 8:33 PM, Jonathan Fletcher wrote:

> PSoS is very powerful. It can save you a boatload of network traffic if your connection is, um, less than optimal.
>
> Create PSoS scripts to have a switch. They shouldn’t run if the file isn’t hosted or if some other condition is met, like a key combination or a global variable you set manually. That way it can debugged locally to make sure that it runs cleanly. Then when you run it on the server you can also check the server logs to see what kind of errors it generates.
>
> Also:
> . Be careful that anything that gets sent to the server is a server compatible script step.
> . Remember to plan around any window or layout script triggers that will run.
> . Do lots of error capture.
> . Either return your errors to the calling script, or log them in a table that you can pull up in your solution.
>
> Just some tips.
>
> Jonathan
>
>
>> On Apr 25, 2017, at 11:15 PM, Riley Waugh <[hidden email]> wrote:
>>
>> PSOS will run a script on the server .  It is triggered from the client but then is all on the server… if a long process it can be initiated form the client and the client can disconnect and it continues to run until completed on the server.  (unless the PSOS script is set to wait for completion).  Which brings up a caution.  Be sure to thoroughly test your script before running it via PSOS.  A script that has an endless loop will run essentially forever on the server if triggered by PSOS.
>>
>> Of course the same goes for a script triggered by schedule on the server.
>>
>> Riley Waugh
>> [hidden email]
>>
>>
>>
>>
>>> On Apr 25, 2017, at 11:13 PM, Stephen Wonfor <[hidden email]> wrote:
>>>
>>> Hi
>>>
>>> What might be the difference between PSOS and actually having the server run a schedule - in terms of performance?  Doesn't PSOS still involve the client machine?
>>>
>>> Stephen
>>>
>>> ---
>>>
>>> "Those who believe in telekinetics, raise my hand." --- Kurt Vonnegut
>>>
>>>> On Apr 25, 2017, at 9:04 PM, Riley Waugh <[hidden email]> wrote:
>>>>
>>>> +2
>>>>
>>>> Riley Waugh
>>>> [hidden email]
>>>>
>>>>
>>>>
>>>>
>>>>> On Apr 25, 2017, at 10:56 PM, Jonathan Fletcher <[hidden email]> wrote:
>>>>>
>>>>> +1
>>>>>
>>>>>
>>>>>> On Apr 25, 2017, at 8:53 PM, Richard DeShong <[hidden email]> wrote:
>>>>>>
>>>>>> Since the user has a slow/unreliable connection, no matter which method you use - please consider using Perform Script on Server. This will start a "client" on the server and run your script - much more reliable (and way faster).
>>>>>
>>>>>
>>>>> --
>>>>> Jonathan Fletcher
>>>>> [hidden email]
>>>>>
>>>>> Kentuckiana FileMaker Developers Group
>>>>> Next Meeting: 4/25/17
>>>>>
>>>>> Sent from a device not known for spontaneous combustion
>>>>>
>>>>> _______________________________________________
>>>>> FMPexperts mailing list
>>>>> [hidden email]
>>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>>> _______________________________________________
>>>> FMPexperts mailing list
>>>> [hidden email]
>>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>>> _______________________________________________
>>> FMPexperts mailing list
>>> [hidden email]
>>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
>> _______________________________________________
>> FMPexperts mailing list
>> [hidden email]
>> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au
> --
> Jonathan Fletcher
> [hidden email]
>
> Kentuckiana FileMaker Developers Group
> Next Meeting: 4/25/17
>
> Sent from a device not known for spontaneous combustion
>
> _______________________________________________
> FMPexperts mailing list
> [hidden email]
> http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au

--
Richard DeShong
Logic Tools
510-642-5123 office
925-285-1088 cell

_______________________________________________
FMPexperts mailing list
[hidden email]
http://lists.ironclad.net.au/listinfo.cgi/fmpexperts-ironclad.net.au