I have a lot of things to change including the whole strategy...
Thanks for the responses... It ended up being a whole
number of factors that were slowing the Script down...

Thanks again...
"Miles Thompson" <[EMAIL PROTECTED]> wrote in message
> Why are you building the array? Why not let SQL do the work?
> Select col1, col2, col3, ... coln from target_table where
> field_holding_target_value = '$target_value_i_want'
> If you have no records returned, then no match, otherwise you have one or
> more matches. In the second case you can proceed with your processing.
> also noted Chris Hewitt's suggestions re number of connections, etc.;
> that's worth checking as well.
> See below as well ...
> Cheers - Miles Thompson
> At 04:00 PM 7/11/2002 -02-30, Kondwani Spike Mkandawire wrote:
> >Hallo folks:  (Sorry for a repost on the same topic just
> >that my first one never got through)...
> >
> >I have a bit of an issue with Paradox Table Searching...
> >I have a fairly large table (4MB+), here is the problem:
> >
> >When I run a search for an element in the Table on
> >my localhost which is running Apache and php 4.1,
> >I have no issues with speed...  However when I run it
> >on the Server at my work place, which is running IIS
> >Server (I am not sure which version), and the same
> >PHP version on my Workstation it takes ages to execute...
> >
> >I have gotten suggestions and have revised my Script
> >over and over using odbc_exec() with SQL commands
> >SELECT myColumn FROM myTable, I have used
> >a COUNT SQL command suggested on this forum,
> >My general algorithm is as follows...
> >
> >1)  I create an Array using odbc_fetch_array this Array
> >      contains one column from the Table I am searching...
> How are you populating the array?
> >2)  Keep trying to matchup each element in the array
> >      against the validation element being checked...
> >      returning found within a sequential loop...
> >      and eventually "Not Found"...
> Are you hitting the database each time through the loop, or stepping
> through the result set?
> How many elements in the array?
> >3)  I suppose the sequential loop is whats killing me,
> >       but the table is not ordered hence I am forced to
> >       do a sequential search..  Does anyone else have
> >       an idea for a quicker and much more efficient
> >       algorithm...
> What reasons are there for not ordering the table? Indexes speed things up
> dramatically, for both the users on the LAN and those accessing via the
> 'Net. Use indexes, they're your friend!
> >Once again the issue of Speed is a non-factor on
> >my local machine running Apache but it does become a
> >factor when I run it on our Server, which is running an
> >IIS Server...
> >
> >Thanks in advance...
> >
> >Kondwani

PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php

Reply via email to