On Nov 30, 2009, at 11:41 AM, Bob McConnell wrote:
From: Rahul S. Johari
On Nov 30, 2009, at 11:07 AM, Bob McConnell wrote:
even though the dbf has 10K records
Fox can't spend "minutes" to found a match
by the way, its very strange
to have 35 columns in a table/dbf or whatever....
pay attention to the comment of Ashley
in Fox, you should:
INDEX on phone_number to idx_directory_phone
- or -
INDEX on phone_number tag phone of cdx_directory
i worked with Fox
with dbfs of 2 millions of records
and the speed is amazing -- using indexes of course!
It has been a long time since I worked with either FoxPro or dBase,
IIRC, both required you to explicitly create any indexes they might
need. They don't have query analyzers like Postgres, MySQL and other
modern DBMS engines.
That is correct! But in my case - I DO indeed have Indexes created
manually. FoxPro created .CDX files for Indexes. The problem is -
PHP use those indexes?
And the secondary question is whether you have enough memory to
'permanently' cache those indexes? They don't improve performance very
much unless they are kept in local memory all the time. The only way
fix this is to move to a real DBMS engine.
Well that might be a problem. The indexes, along with the files, are
stored on the network and they are accessed over the network, not
locally. Although to be fair; I have tried using a copy of the DBF &
it's Index File (CDX) locally and it didn't make any difference to the
Either way, it all points in the same direction ... using a modern
DBMS. It's just a problem on our end because all our customer data is
in FoxPro databases and all the other applications are written for
those FoxPro databases.
Rahul Sitaram Johari
Founder, Internet Architects Group, Inc.
PHP General Mailing List (http://www.php.net/)
To unsubscribe, visit: http://www.php.net/unsub.php