From: jmose@mapson.attglobal.net   
      
   spurohit,   
      
   If I remember correctly, each secondary index reduces the table's maximum   
   record count.  So, although you might not be running into the 'theoretical'   
   limits on the table, you might have hit this.   
      
   If you have a secondary index that starts with the primary key, drop it since   
   it is useless.  This might help alleviate the problem.  The only downside   
   would be any forms/scripts/libs/data models that open the table using that   
   index need to be changed.  You could probably scan the code for that index   
   name, using window's Search button.   
      
   Also, increasing the block size of a table can have a definite impact on   
   you system response. In my experience, using peer-to-peer networking, every   
   time you open a table you get 8 blocks of data sent to you, which I assume   
   is to speed up sequential processing.  This is all wasted for random   
   processing,   
   which most interactive systems will use.  Since every user is now getting   
   'wasted' data, that can cause your network to grind to a halt.  (The more   
   data sent, the more retries are needed, ad infinitum.)   
      
   Finally, is it just this query that is slower, or other aspects of your system?   
    You could put more indexes on the table to have them used by this query   
   - a single-field secondary index on this particular field would definitely   
   help this query. But, as you've seen, adding indexes can affect other parts   
   of your app.   
      
   HTH,   
   Jim Moseley   
      
   --- SoupGate-Win32 v1.05   
    * Origin: you cannot sedate... all the things you hate (1:229/2)