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. I've
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
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
>Thanks in advance...
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php