From: mike@liny.com   
      
   Just a guess but the problem is probably the indexes.  PX is the file   
   extension for the primary index or key.  You have a compound key which   
   can be a very large file.  If you can you may want to add another field,   
   an meaningless integer and use that as a the key.  You can add secondary   
   indexes where appropriate to enhance query performance.  I would get a   
   copy of Paradox (not expensive) and play around with restructuring the   
   table and indexes and see what happens to query speed.  Of course you   
   can do all this with SQL, but a visual interactive approach by using   
   Paradox may speed up your research.   
   Another possibility is the design of your network.  There are several   
   threads on the optimal way to set up a network.  Check out   
   thedbcommunity.com.   
   If you are using a client server system, you get better performance if   
   the queries are run remotely (on the server).  There is an option on   
   Paradox as to where the queries are run.  Give us a few more details   
   about your network, what machines you are using and we can give you more   
   help.   
      
   > Hi everyone,   
   > First off, I am very new to using Paradox tables, so I am stumped as   
   > to how I should go about addressing these problems.   
   >   
   > Anyway, I have a C# application that needs to access a Paradox   
   > database over a network (through an ODBC connection).  I have   
   > successfully been able to do this in the past, but when I tried to   
   > deploy a change this morning, the performance was intolerable and even   
   > crashed my application.  At first, I thought that I simply couldn't   
   > connect, but it turns out that the queries are not performing well.   
   >   
   > For example, if I run the following query:   
   > SELECT TOP 1 * FROM ModelSer   
   > or even:   
   > SELECT TOP 1000 * FROM ModelSer   
   >   
   > the query runs fairly well (the latter is slower, obviously).   
   >   
   > Now, the table is (supposed) to be set to have the model, serial, and   
   > timestamp set as the primary key.  This would lead me to expect that   
   > if I try this query:   
   > SELECT TOP 1 * FROM ModelSer ORDER BY Timestamp   
   >   
   > ...that it would run fairly quickly.  However, that wasn't the case.   
   > If I used a test database locally, it took me 2 minutes to get a   
   > response.  At first, I noticed that I didn't have BDE installed.  I   
   > installed it and noticed no performance difference.  However, if I   
   > delete the .PX file corresponding to the table, the performance is   
   > much better.  When I try to restructure it with the primary keys, the   
   > performance sucks again.   
   >   
   > I have doing this kind of thing for about 6 months, but I can't quite   
   > get a handle on what is going on.  Any advice would be greatly   
   > appreciated.   
   >   
   > Sincerely,   
   > Jason Pell   
   >   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)