ZeosLib Components Cached Updates

[DiegoBM]

I'd like to know which level of cached updates implementation comes with zeosdbo components.

I'll try to explain my problem with an example...
I don't really know if this is even possible on actual CachedUpdates implementations, but the matter is that when I post changes in a CachedUpdates-enabled Dataset without committing'em and then I try a Count(*) on the same table but another dataset, the count won't reflex the uncommited modifications.

The point would be a Connection-level CachedUpdates implementation capable to query together the Database and the entire transaction/connection-shared cache for results, as if the cached modifications where posted directly to the Database but remaining in the cache, some kind of "emulation?" of the database's on-post behavior.

Regards an well...sorry for my bad english

[DiegoBM]

Nobody knows?



If not implemented yet, but scheduled, I guess I'd help...

[zippo]

Sorry, but I don't understand the question at all ...

[gto]

Hey zippo, means something like this:

Today, the component cached updates store the modifications in your own cache, each component has one cache, independant from others
without commiting to database, the modifications made in a dataset don't reflect in another.

I think that's the way it work's today.

The idea of DiegoBM is to link all component caches to make a "big application database cache", a level of access that any modification you do in a dataset, but don't commmit, can be viwed from another dataset, in the same program.

Well, I think it's this

[DiegoBM]

Yeah, it's exactly that, a connection-level cache. Thx gto

[btrewern]

Try using ClientDataSets if you want this feature see cloned cursors. It does this kind of stuff and other clever things.

Ben

[zippo]

What about server-side?

BEGIN TRNASACTION, COMMIT,.. etc. ?