At 09:30 PM 28/08/2005 +0000, you wrote:

>Working with TIB_Query or TIB_Cursor, after preparing and opening it,
>it goes to state dss_browse. Even after Unprepare, or Close and
>Unprepare, it remains on that state, it doesn't change to dss_inactive.

dssBrowse is tib_dataset's neutral state, indicating that dataset (whether
open or not) is in a transaction but is not being edited, inserted to,
deleted from or searched. It may or may not be Prepared when it is in this
state.

"Closing" a dataset causes the query to complete fetching rows. It's just
a matter of finishing a part of the logical task: it doesn't do anything
to affect the physical transaction or the availability of the dataset. If
the transaction isn't either committed or rolled back, Unprepare doesn't do
anything.

The only times a dataset will be in dssInactive are when there is no
transaction; and following the hard Commit of a delete operation (as long
as the transaction is not Autocommit).

>I feel it's strange, it's not what happens with TIBQuery or TADOQuery
>and so on. Why?

Why would IBO want to emulate them? They provide no distinction between
the logical and physical aspects of a task.

What do you need to do, that requires the dataset to be in dssInactive
state? If you have a persistent statement object that you want to keep
available, you will "shut it down" by closing and then unpreparing it. It
won't use any resources in this state.

If it is one you use only once, consider creating it, using it and then
destroying it.

Helen