From: mike@liny.com   
      
   Jason,   
   See in line   
   >   
   > First, I have no control over the network because we are contracting   
   > with large corporation and have to use whatever network they are   
   > using.  The ODBC driver that I am using is the Microsoft Paradox   
   > Driver.  This is where I discovered something...in my test   
   > environment, I was actually using Paradox 5.0.  Unknown to me, they   
   > had upgraded to Paradox 7.0.  Apparently, the Microsoft Paradox Driver   
   > doesn't support 7.0.   
      
   The main difference between tables >5.0 is the availability of   
   descending indexes in the newer Paradox tables.  If your tables are >7.0   
   the MS driver should be fine.  I'm not sure that the ODBC driver has   
   anything to do with your query speed.  If you can open the table with a   
   non Paradox app, then the driver is working.   
      
   I have since explored the Merant(?) ODBC driver   
   > and have made some progress there.  Does this seem to be the correct   
   > route to take?  I am much more familiar with MySQL and MSSQL, and we   
   > are trying to slowly move away from Paradox so that we are consistent   
   > in with DBMS's.   
   >   
   > To answer some more questions, there are about 300,000 rows in   
   > ModelSer on my test environment.  I'm not sure how many are on the   
   > actual machine (I'm actually taking a day off from work today, so I'm   
   > not in the office), but it is probably about the same.  When I strip   
   > off the PX driver, it takes probably 20 seconds to run the query.   
   > When the PX table is there it takes about 140 seconds.  To be   
   > specific, this is the query where I order by Timestamp.  To   
   > restructure the table, I am using Borland Database Desktop 7.   
      
   Your primary index (px file) is probably the reason for the slow   
   performance.  You mentioned that it is a compound key (more than one   
   field).  The PX file must be huge if you have 300,000 rows (records).   
   See for yourself with windows explorer how big the .px file is and how   
   big the .db file is for that table.  If you restructured your table and   
   added an integer field using the integer field for the key, that new   
   field would be the source of the .px file for that table.  The size of   
   the new .px file would be much smaller than the compounded key that is   
   currently your .px file, and therefore your queries should execute   
   faster.  Also have the query executed on the server.   
   >   
   > Finally, I apologize if this is the incorrect newsgroup, but as I   
   > mentioned earlier, I have little experience with Paradox, so this   
   > seemed to be a good fit as to where to get help.  Thanks again,   
   > everyone!   
      
   Your post is very appropriate for this newsgroup and all of the   
   newsgroup participants will benefit from your problem and how it gets   
   resolved.  We are more than happy to help.  Please let us know what you   
   do so we can learn from your experience.   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)