Subject | Tib_SyncCursor and delay calling prepare method |
---|---|
Author | Luiz |
Post date | 2003-10-04T17:08:04Z |
Only as information to others ibo users.
I have used dmlcache for a long time in my apps and I was noting a long
delay when my app was connecting to database, after some months.
My problem was I had a Tib_SyncCursor that I was calling your prepare method
just after the success on connection to DB.
The prepare method of Tib_SyncCursor issues a 'select max(dmlid) from
ibo$dmlcache'.
After some time the table ibo$dmlcache becomes too big and the 'select max',
takes a long time.
I have seen two options to avoid this delay:
1. It was suggested that the user must to do a clean up of this table
periodically, as was suggested here days ago, or
2. Create a descending index on dmlid field of the table ibo$dmlcache, to
avoid the long delay when calling prepare method of Tib_SyncCursor. Thats
work very well.
I have used a mix of both.
Luiz.
I have used dmlcache for a long time in my apps and I was noting a long
delay when my app was connecting to database, after some months.
My problem was I had a Tib_SyncCursor that I was calling your prepare method
just after the success on connection to DB.
The prepare method of Tib_SyncCursor issues a 'select max(dmlid) from
ibo$dmlcache'.
After some time the table ibo$dmlcache becomes too big and the 'select max',
takes a long time.
I have seen two options to avoid this delay:
1. It was suggested that the user must to do a clean up of this table
periodically, as was suggested here days ago, or
2. Create a descending index on dmlid field of the table ibo$dmlcache, to
avoid the long delay when calling prepare method of Tib_SyncCursor. Thats
work very well.
I have used a mix of both.
Luiz.