if you rename the x* fle, to something.db, it IS a table you can work
with..
but then you'd need to do a 2nd query to grab the remaining info you'll
need, from the main table.. and, FWIW, you're still doing a dot-dot query,
that has to go thru all records..
--
Steven Green - Myrtle Beach, South Carolina USA
Diamond Software Group
http://www.diamondsg.com/main.htm
Paradox Sup****t & Sales
Diamond S****ts Gems
http://www.diamondsg.com/gemsmain.htm
S****ts Memorabilia and Trading Cards
"Jim Moseley" <jmose@[EMAIL PROTECTED]
> wrote in message
news:4716f748$1@[EMAIL PROTECTED]
>
> 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
|
