Subject | Re: [IBO] support for 2 transactions in ib_query |
---|---|
Author | Daniel Rail |
Post date | 2004-07-02T12:09:59Z |
Hi,
At July 1, 2004, 08:13, Helen Borrie wrote:
there might be some limitations/complications and would require some
work, to make it work. Read below for more details.
properties: one specifically for the SelectSQL property and another
for InsertSQL, UpdateSQL, DeleteSQL and RefreshSQL properties. The
RefreshSQL property contains the DML to refresh the current row. So
the data seems to be buffered, and when an Insert is performed, the
row is simply added into the buffer and then refreshed using the
RefreshSQL and the key values for the row.
One thing that seems to pop out at me, how is the ordering of the rows
managed with FIBPlus, if the original Select has been executed and
thereafter you insert and update rows, that would affect the sort
order of the result set. The only answer that I can think of is that
there's some sorting performed in the buffer on the client, and that
any additional rows fetched from the server will have to be sorted by
the client.
My preferred way is to have one read-only TIB_Query(or TIBOQuery)
attached to a read-only transaction for viewing data in a grid and
searching. And, then use a read/write TIB_Query(or TIBOQuery) attached
to a read-write transaction for editing the selected row in a popup
form.
--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)
At July 1, 2004, 08:13, Helen Borrie wrote:
> At 11:33 AM 1/07/2004 +0300, you wrote:I think it would be possible to use 2 separate transactions. But,
>>Thank you for replying so quickly to my post, but you still haven't
>>answered to my question: will there be support for 2 transaction in
>>ib_query (one for the select and the other for insert/update/delete)?
>>Or you did answer to my question but in a less direct way and the answer
>>was no?
> No. One IB_Query cannot be in two transactions. That isn't an IBO
> limitation: it's a database rule.
there might be some limitations/complications and would require some
work, to make it work. Read below for more details.
> What FIBPlus does, it starts a NEW transaction when it performs each DMLI read the FIBPlus documentation, just for fun. There are two
> operation. With IBO, if you want to follow this model, use a TIB_DSQL in a
> separate transaction for your DML operations. If you want to be able to do
> it in one shot, by default, without considering the consequences for
> contention and integrity, then use FIBPlus.
properties: one specifically for the SelectSQL property and another
for InsertSQL, UpdateSQL, DeleteSQL and RefreshSQL properties. The
RefreshSQL property contains the DML to refresh the current row. So
the data seems to be buffered, and when an Insert is performed, the
row is simply added into the buffer and then refreshed using the
RefreshSQL and the key values for the row.
One thing that seems to pop out at me, how is the ordering of the rows
managed with FIBPlus, if the original Select has been executed and
thereafter you insert and update rows, that would affect the sort
order of the result set. The only answer that I can think of is that
there's some sorting performed in the buffer on the client, and that
any additional rows fetched from the server will have to be sorted by
the client.
My preferred way is to have one read-only TIB_Query(or TIBOQuery)
attached to a read-only transaction for viewing data in a grid and
searching. And, then use a read/write TIB_Query(or TIBOQuery) attached
to a read-write transaction for editing the selected row in a popup
form.
--
Best regards,
Daniel Rail
Senior System Engineer
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.filopto.com)