Forums before death by AOL, social media and spammers... "We can't have nice things"
|    comp.databases.paradox    |    To crash or not to crash, asks Borland    |    9,834 messages    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
|    Message 8,854 of 9,834    |
|    Jim Moseley to All    |
|    Query directly from secondary index    |
|    18 Oct 07 02:03:52    |
      From: jmose@mapson.attglobal.net              Greetings all.              I think I've stumbled onto a way to speed up queries, but am looking for       a second opinion.              I have a table with several secondary indexes, one of which contains the       'Name' & 'Key' fields. I want to perform a generic match on the 'Name' field,       to return all rows that have Name = "..Jim..".              If I perform my query on the DB file, it will open & search the entire table,       ignoring the 2nd index because of the wildcards.              If I perform my query directly against the appropriate XG* file, it will       perform the query on a 'mini-table' of just the Name & Key columns, which       should be much smaller than the entire DB table.              Does this make sense?              For example:              Query       Customer.XG1 | Key | Name |        | Check | CheckPlus ..Jim.. |       endQuery              Note that I tried to open a tcursor against the 'Customer.XG1' file & it       wouldn't let me. The query engine must work differently.              Extra credit: by doing a enumIndexStruct on the table, does the iIndexID       column map directly to the 'XG*' name, as 'X' + string(hex(iIndexID + 1))?        I'm guessing this is the case, because the iIndexID values start with 256       and go up by 1 for each additional index.              Thanks,       Jim Moseley              --- SoupGate-Win32 v1.05        * Origin: you cannot sedate... all the things you hate (1:229/2)    |
[   << oldest   |   < older   |   list   |   newer >   |   newest >>   ]
(c) 1994, bbs@darkrealms.ca