[ic] Trouble with coordinated search to test for inactive

[Ron Phipps]

> From: Grant
> 
> [snip]
> 
> > > There is nothing wrong with custom searches. It is
> > just important
> > > to know the downsides and counterpoints.
> >
> > I'm seeing this more and more as I work with my
> > custom query page.  I'd
> > really like to use the built in search, but there is
> > no reason apparent
> > to me why these searches are not working.
> >
> > -Ron
> 
> I'm trying to make sure I understand IC and searches.
> By "custom searches" do you mean searches using the
> SQL IC tags, and by "built in search" do you mean the
> loop functionality?  I've only used the loops for
> searches, but I was under the immpression that that's
> what you do until you learn the SQL tags.  Maybe
> that's not right?

You got it.  A custom query page would take parameters to it, make those
parameters safe and then put them into a query call which would return
the results and display them.  I use these types of pages when showing
all the subcategories in a category. Or all the products in a
subcategory.  Since the parameter list is finite and does not change
it's easy to make 1 page that does this job very well.  You can also
control the input to those parameters with a simple filter call that
filters out all non word characters or all non digit characters.

A page using the normal search/scan functionality of IC is more flexible
in that I can change the results by adding on a couple extra parameters,
but the actual results page does not change.  It is simply a
[search-region] / [search-list] which shows the results.  The actual
searching is all built into IC and you don't have to rewrite a query
every time you want to add an additional parameter.  This type of page
in my mind is best suited for a page where a user wants to search the
products table for a certain string.  In this situation the user is able
to directly change what value is sent to the search page and as a result
that entry needs to be cleaned thoroughly to make sure it cannot cause
any harm.  From what I can tell the search/scan functionality already
has those routines built in.

> Maybe the pros and cons break down like:
> 
> SQL searches: more powerful, faster
> loop searches: safer
> 
> ?
> 
> - Grant

After working with the search/scan functionality I think it is pretty
powerful and is fast.  The key is to structure your parameters so the
results are cut down in the first query to the db as much as possible
then IC will loop over those results and remove the remaining records
that do not match the rest of your conditions.  It's also a real smart
idea to use the "rf/mv_return_fields" parameter so that all the fields
you need to access on your results page are available without hitting
the database again.  This is as simple as putting the fields in the rf
parameters and then replacing [prefix-field fieldname] with
[prefix-param fieldname].  This cuts down on the db access heavily.

There will probably be some things you cannot do with the search/scan
functionality, but as Mike showed me what I thought wasn't possible was
and it seems to do the job better then any custom query page I could
write.

Thanks!
-Ron