[ic] Trouble with coordinated search to test for inactive

Grant emailgrant123b at yahoo.com
Fri Apr 9 13:08:26 EDT 2004


--- Ron Phipps <rphipps at reliant-solutions.com> wrote:
> > 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

Thank you Ron.  It's great to get information broken
down like that.  I think I know where custom and
built-in searches belong now, and I will definitely be
putting your built-in search optimization tips to use
right away.  I didn't realize the order of the queries
in a search would make any difference and the rf
parameter sounds like a great way to optimize things
even further.  Thanks again!

- Grant

__________________________________
Do you Yahoo!?
Yahoo! Small Business $15K Web Design Giveaway 
http://promotions.yahoo.com/design_giveaway/


More information about the interchange-users mailing list