Subject | RE: [IBO] IBO 4.9.14 Build 11 released. |
---|---|
Author | Support List |
Post date | 2011-07-15T21:17:04Z |
Thomas,
the same transaction and it would need to see it's own changes regardless of
the isolation level. There is still an argument for doing this if the
transaction was both read-only and concurrency but since the default is to
not check the server I didn't worry about it. I figure people will only turn
that feature on when they actually want it. And, if they turn it on in a
senseless context they can have the lack of efficiency.
Make sense?
Thanks,
Jason LeRoy Wharton
www.ibobjects.com
> > I've fixed a couple issues and released a new version.I decided against distinguishing since you could have two queries against
> >
> > This release should resolve Thomas's issue calls to Locate() generating
> > a fetch from the server looking for a record that it couldn't find.
> > Thomas wanted the Locate() method to not bother checking on the server
> > if all ofthe records were already fetched into the client buffers.
> > I decided this would be a good thing and made it default to not check
> > the server but if you still want the old behavior you can add the
> > lopCheckOnServer option in the call to Locate() if you want it to make
> > sure.
>
> Great! Will reduce network traffic a lot and give me in-memory locates
> for an entirely fetched result set.
>
> I haven't looked into detail, but is the behaviour also dependend on the
> transaction isolation level as we have discussed via Skype?
the same transaction and it would need to see it's own changes regardless of
the isolation level. There is still an argument for doing this if the
transaction was both read-only and concurrency but since the default is to
not check the server I didn't worry about it. I figure people will only turn
that feature on when they actually want it. And, if they turn it on in a
senseless context they can have the lack of efficiency.
Make sense?
Thanks,
Jason LeRoy Wharton
www.ibobjects.com