Subject | Re: [IBO] Yet Another BDE emulation issue. Transactional Isolation issue I think. |
---|---|
Author | Randal W. Carpenter |
Post date | 2007-06-29T14:35:51Z |
Are these getting to the list?
At any rate, I changed the start trans, try to commit or rollbacks to
start trans, try commitretaining or rollbacks, then did a if in trans
rollback when I closed out the list. I did this several places and it
seems to better emulate the bde. I think what ibo does is put everything
under the same transaction once you start a new one on a cached
update...the bde left the data before you starting the transaction in the
old transaction state somehow...that is ibo is refreshing the data too
well :). Both the bde and ibo were set to read commit so I am at a loss
as to why they act different...maybe because bde has more middleware in
there or something?
At any rate this also sped up my application somewhat too on the remote
sites, now updates that took 8-10 seconds are back down to about a 1/2
second. Once I go through and make sure ibo is using the best plan (which
it does not do so well where the bde guess good...probably because I am
using firebird 1.0 on dialect 1, and its optimized for the 2.0 engine on
dialect 3 maybe), this thing should really fly. See my other post "My IBO
port is too slow...need performance advice" as this seems to help with
that too. I would still appreciate some general performance advice
though.
thanks,
Randal
At any rate, I changed the start trans, try to commit or rollbacks to
start trans, try commitretaining or rollbacks, then did a if in trans
rollback when I closed out the list. I did this several places and it
seems to better emulate the bde. I think what ibo does is put everything
under the same transaction once you start a new one on a cached
update...the bde left the data before you starting the transaction in the
old transaction state somehow...that is ibo is refreshing the data too
well :). Both the bde and ibo were set to read commit so I am at a loss
as to why they act different...maybe because bde has more middleware in
there or something?
At any rate this also sped up my application somewhat too on the remote
sites, now updates that took 8-10 seconds are back down to about a 1/2
second. Once I go through and make sure ibo is using the best plan (which
it does not do so well where the bde guess good...probably because I am
using firebird 1.0 on dialect 1, and its optimized for the 2.0 engine on
dialect 3 maybe), this thing should really fly. See my other post "My IBO
port is too slow...need performance advice" as this seems to help with
that too. I would still appreciate some general performance advice
though.
thanks,
Randal
On Thu, 28 Jun 2007, Randal W. Carpenter wrote:
>
> Hi,
>
> If I pull up a query as a grid list then from the list I pick a record to
> work on (say I double click on the grid) then I brings up the record in an
> edit screen...if i update while looking at the list, it takes the record
> out and pops up the next one if it no longer meets the criteria of the
> search. I start a new transaction before I update...to make sure the list
> is in another transaction from the record update...but I don't think that
> is working as it did in the bde.
>
> So how do I make it act like the BDE and leave my list alone and not
> auto-matically refresh the query and take out the record I am looking
> at when I commit changes to that record? My transaction isolation is the
> same as it was in the bde (read committed) so I am at a loss.
>
>
> Randal
>