>>> I've fixed a couple issues and released a new version.
>>>
>>> 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?
>
> I decided against distinguishing since you could have two queries against
> 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?