| Subject | RE: [IBO] IBOTable findkey functionis too slow and reason?? |
|---|---|
| Author | Jason Wharton |
| Post date | 2019-05-17T06:29:39Z |
If you can reproduce anything that is undesirable behavior in
a sample app I would gladly investigate it. I am also happy to do a remote
desktop debugging session with you if you like. Just contact me directly
on Skype (jason.l.wharton) or via direct email at support@....
Thanks!
Jason Wharton
www,ibobjects.com
From: IBObjects@yahoogroups.com [mailto:IBObjects@yahoogroups.com]
Sent: Friday, May 17, 2019 12:26 AM
To: IBObjects@yahoogroups.com
Subject: RE: [IBO] IBOTable findkey functionis too slow and reason??
Hello Jason,
Thank you for the reply. Firstly, yes I'm using a
TIBOTable.
I have previously tried creating a descending index on those 3 fields as
well, as I read that Firebird indexes are not bidirectional.
However, alternating indexnames to sort based on different columns was
eventually causing an error, as described in case #48899 in this Yahoo groups a
few days ago.
We somehow found a way to circumvent this error by applying the following
pseudo-code every time we want to sort based on a different column:
1) de-activate the table
2) set index name := new_index_desc
3) set index name := new_index_asc
4) activate the table
at this point, I was successfully able to apply the following operations in
a split second, on a table with 1,400,000 records: first, last, findKey.
But, if I was to omit step 2), then the last operation was yielding incorrect
results, likely based on the previously "cached"
index?
The problem at this point is, everything I am doing is
based on speculations of how IBO should work, and a knowledgeable opinion on the
matter would be extremely constructive.
Thanks again for your time,
Khatchig