"Claudio Valderrama C." <cvalde@...> wrote in message
news:a4cl3e$hb0$1@......

> And have you tried to debug? I understand that you are are using two
> threads. It's possible to debug where the second thread stalls in your app
> to know what to blame at least.
> You need separate sessions => separate connections.

I'm starting to get conflicting ideas. Generally the second one has got to the
place where it is opening the main query.

I'm using IBX, with a separate TIBDatabase component. I don' think sessions are
involved.

> Make sure the isolation level is either repeatable read (snapshot,
> concurrency) or read committed, depending on your needs. If it's RC, then
> don't use "no wait" with "no record_version". In fact, never use "no

How do I do all this? There are no eqivalent properties in TIBDatabase? Do I
have to put that in the TIBDatabase's params?

> record_version" under normal operations. Make sure your app doesn't have a
> conflict when accessing the GUI part from two threads. I assume your query
> is a SELECT, not an update that can have conflicts in the engine with the
> first thread. Don't go to the extreme of reserving tables for the
> transactions unless you know what you are doing with such advanced feature.
> Etc.

It's just a SLECT, I'm not doing anything fancy.

>
> Have you tried a simple case with datasets that don't have a datasource
> neither visual controls attached? You could put a BEEP after the call to
> OPEN or ACTIVE to see if the command returned or is stalled, since you won't
> have visual feedback.

There are no dataaware controls involved when it seizes up. It's just preparing
data for a TQuickRep.

Thanks,
Mark