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

Kevin Futter kfutter at sbc.melb.catholic.edu.au
Wed May 9 17:15:56 MDT 2007


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/20070510/7009a04d/attachment.html


More information about the FX.php_List mailing list