[FX.php List] filemaker script error catch

[Alex Gates]

Thanks ggt and Joel -

The script does set a field from 0 to 1 on each record... so I do a 
simple query for 0... if I have a foundcount !=0, then obviously my 
script failed.

Thanks for the help!

Joel Shapiro wrote:
 > Hey Alex
 >
 > Could you have the FM script set a global to Get(LastError) -- and 
then ExitScript if != 0 -- at places it might fail, and then check the 
global in the PHP?  Don't know if it would work... just a thought.
 >
 > As to "not advised"...  That's what I'd always understood but I 
emailed with Lance Hallberg about this last year, and he replied:
 >
 >> ...certainly depends on what the FileMaker script is doing and what 
PHP can do...
 >>
 >> FM scripts can be a big load on the server, but in most cases no 
bigger that executing those actions from php.
 >>
 >> For example try running a script from the web which creates 40,000 
records.  Now try to do this by purely using PHP.  Notice which one is 
faster.
 >>
 >> Consider running batch scripts... such as de-duping... on a large 
set of records.  Large inserts or number crunching scripts will always 
perform better then FM Script execution than by PHP loops.  Certainly 
this is mostly due to the need for multiple database transactions... to 
the nth degree.
 >>
 >> While the create 40,000 records script is running you can also run 
PHP scripts which perform finds, add & delete records.  You can even 
execute more FM scripts from php while the previously executed script is 
still running.  The notion that the WPE is 'holding back other queries 
until done running the script' is completely wrong.  I'm not sure how 
that ended up on the thread but it could be just dated facts; perhaps 
that was an issue with FM 6?
 >>
 >> The huge (and unexploited) advantage to running scripts is the 
notion of being able to re-use FM logic that already exists.  Also, 
consider an FM solution using multiple users and access priv's in the 
deployment model.  Allowing some to access the layout used for the 
script or even the script themselves, is a great way to disperse 
application control without leaving the FM environment or giving access 
to your PHP code.  Make sense?
 >
 > I still generally try to do most processing in the PHP, but good food 
for thought.
 >
 > -Joel
 >
 >
 >
 > On May 29, 2008, at 7:46 PM, Alex Gates wrote:
 >
 >> I know it is not advised to trigger a FM script using fx.php, but I 
was wondering if there is a way to catch the error if something goes wrong.
 >>
 >> Any ideas?
 >> _______________________________________________
 >> FX.php_List mailing list
 >> FX.php_List at mail.iviking.org
 >> http://www.iviking.org/mailman/listinfo/fx.php_list
 >
 >



Joel Shapiro wrote:
> Hey Alex
> 
> Could you have the FM script set a global to Get(LastError) -- and then 
> ExitScript if != 0 -- at places it might fail, and then check the global 
> in the PHP?  Don't know if it would work... just a thought.
> 
> As to "not advised"...  That's what I'd always understood but I emailed 
> with Lance Hallberg about this last year, and he replied:
> 
>> ...certainly depends on what the FileMaker script is doing and what 
>> PHP can do...
>>
>> FM scripts can be a big load on the server, but in most cases no 
>> bigger that executing those actions from php.
>>
>> For example try running a script from the web which creates 40,000 
>> records.  Now try to do this by purely using PHP.  Notice which one is 
>> faster.
>>
>> Consider running batch scripts... such as de-duping... on a large set 
>> of records.  Large inserts or number crunching scripts will always 
>> perform better then FM Script execution than by PHP loops.  Certainly 
>> this is mostly due to the need for multiple database transactions... 
>> to the nth degree.
>>
>> While the create 40,000 records script is running you can also run PHP 
>> scripts which perform finds, add & delete records.  You can even 
>> execute more FM scripts from php while the previously executed script 
>> is still running.  The notion that the WPE is 'holding back other 
>> queries until done running the script' is completely wrong.  I'm not 
>> sure how that ended up on the thread but it could be just dated facts; 
>> perhaps that was an issue with FM 6?
>>
>> The huge (and unexploited) advantage to running scripts is the notion 
>> of being able to re-use FM logic that already exists.  Also, consider 
>> an FM solution using multiple users and access priv's in the 
>> deployment model.  Allowing some to access the layout used for the 
>> script or even the script themselves, is a great way to disperse 
>> application control without leaving the FM environment or giving 
>> access to your PHP code.  Make sense?
> 
> I still generally try to do most processing in the PHP, but good food 
> for thought.
> 
> -Joel
> 
> 
> 
> On May 29, 2008, at 7:46 PM, Alex Gates wrote:
> 
>> I know it is not advised to trigger a FM script using fx.php, but I 
>> was wondering if there is a way to catch the error if something goes 
>> wrong.
>>
>> Any ideas?
>> _______________________________________________
>> FX.php_List mailing list
>> FX.php_List at mail.iviking.org
>> http://www.iviking.org/mailman/listinfo/fx.php_list
> 
>