[FX.php List] Confusion with 'not equals' search

[Chris Bisgard]

Thanks, Kevin, for that info. I'm running FMSA ver 8 on a site that gets
pretty light traffic, and haven't seen any performance impact. While I do
get the "it feels wrong" thing, in some cases it has been the most expedient
solution for me. As my PHP skills improve, I suspect I will choose to use
the -script 'crutch' less and less. 
 
You mentioned security issues and data sync integrity. What are the concerns
there? My current scripts don't make changes to records, they only constrain
the found set. I assume data sync and security concerns would be for running
scripts that actually enter data, update calc fields, edit globals, etc.?
 
Thanks,
Chris
 
----------------------------------------
Chris Bisgard
Information Technology Specialist
Regional Arts & Culture Council
108 NW 9th Avenue, Suite 300
Portland, Oregon 97209-3318


  _____  

From: fx.php_list-bounces at mail.iviking.org
[mailto:fx.php_list-bounces at mail.iviking.org] On Behalf Of Kevin Futter
Sent: Wednesday, May 09, 2007 4:16 PM
To: FX.php Discussion List
Subject: Re: [FX.php List] Confusion with 'not equals' search


On 10/5/07 3:40 AM, "Chris Bisgard" <chris at hotanvil.com> wrote:



This doesn't specifically address Roger's questions about how 'neq' works,
but it raises a related issue I've been wondering about myself... 
 
I have solved similar problems to this one by running the first part of the
query with FX, then using the -script parameter in FX to run a very simple
FileMaker script that constrains my found set to satisfy the second part of
the query. However, I seem to recall some of you on this list advising
against having FX run FileMaker scripts, and I'm wondering why. I know that
I can have FX pull the widest data set and then use PHP to whittle it down
from there, but the FM script method is pretty easy and seems to work fine.
I currently have three production scripts handling mixed-type "and/or"
queries in this way, and I have been unaware of any negative effects.
Conversely, I assumed that having FX pull a much larger found set than I
need, then filtering the records in PHP, would actually be the bigger
performance drag of the two. Is that wrong? There's a good chance I don't
know what I'm talking about here...
 
Since there's a strong likelihood I'll be doing more of this in the future,
I wondered if anyone would care to back up their belief in one of these
methods over another for mixed-type and multiple-'neq' searches, in terms of
best practice?
 
Thanks,
Chris
----------------------------------------
Chris Bisgard
Information Technology Specialist
Regional Arts & Culture Council
108 NW 9th Avenue, Suite 300
Portland, Oregon 97209-3318



Chris,

There is some confusion about this regarding the latest versions, but
certainly in version 6 and earlier, running internal FM scripts from the web
had great potential for problems. The most important was that, given FM's
single-threaded nature at the time, scripts had to fully execute and return
before FM could respond to any other requests. This could have a potential
impact on performance on even a modestly busy system, but the theory is that
this issue doesn't exist in the newer versions.

Other reasons included security issues, data sync integrity and
philosophically 'feeling wrong'. I've done it myself but do try to avoid it
if there's another way.

-- 
Kevin Futter
Webmaster, St. Bernard's College
http://www.sbc.melb.catholic.edu.au/

  _____  

This e-mail message has been scanned for Viruses and Content and cleared by
MailMarshal 
  _____  


 



  _____  

This e-mail and any attachments may be confidential. You must not disclose
or use the information in this e-mail if you are not the intended recipient.
If you have received this e-mail in error, please notify us immediately and
delete the e-mail and all copies. The College does not guarantee that this
e-mail is virus or error free.  The attached files are provided and may only
be used on the basis that the user assumes all responsibility for any loss,
damage or consequence resulting directly or indirectly from the use of the
attached files, whether caused by the negligence of the sender or not. The
content and opinions in this e-mail are not necessarily those of the
College. 
  _____  




-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.iviking.org/pipermail/fx.php_list/attachments/20070511/2340a04a/attachment.html