Hi Olivier :)

> You shouldn't. Wanted to make sure Commit was used.
> Asking the obvious, are you 100% sure of the signaling between the
> threads ?
>

yeah :)

> Now to the SQL side of things, I would have expected that thread 2,
> preparing and running a query inside a read-committed transaction
> would see others attachment committed transactions data immediately
> with no caching of any sort altering the result.

I'm wondering myself as well...

> Is this assumption wrong ?
> Should this be considered a bug ?
> When one says that a read-committed transaction sees committed data
> by other transactions, how should this be interpreted? A read-
> committed trans can and will probably, soon, see other committed
> updates? Or a read-committed trans _must_ see other commits immediately?

urh, I'd assume it must? :) anyone else to help us on this?

>
> Zach, how many other threads/processes have you running and what do
> they do ?
> Isn't this just an expected side-result of versioning ?

There's one GUI thread, but that's it.

> Could you re-run your test using IBPP::ilReadDirty and report again
> (which is read_committed with rec_version while ilReadCommitted is
> read_committed with NO_rec_version) ?
>
> (I doubt this is IBPP related. If it turns to be, we'll move the
> thread to the list where it belongs.)
>

ok, will try it and report back later.

Thanks again Olivier, you've been helping me out a LOT!

truly appreciate that.