Roy Lambert wrote:

>Well, if Tim moves to a totally ElevateDB managed file system, c/s only engine then it should be possible since
>he can hold flags in engine accessible memory to say wether data has been changed or not. There will still be a
>need to TDataset compliance at some level or Tim will have to write a new component set to allow you to see
>your data.

I don't think it is as complicated as that.

If the fk table is inside of the transaction (or the table is locked), the table can't be updated by outside processes (even non C/S) so any changes inside the transaction to the fk table (which in my case never happens) will still be in the EDB cache so no need to go to disk. When the transaction is committed, and a new transaction started then the cache needs to be rebuilt. But since the transaction has around 5k rows it will still save a lot of disk access when validating the FK.

Barry

Barry


>I don't think it is as complicated as that.
>
>If the fk table is inside of the transaction (or the table is locked), the table can't be updated by outside processes (even non C/S) so any changes inside the transaction to the fk table (which in my case never happens) will still be in the EDB cache so no need to go to disk. When the transaction is committed, and a new transaction started then the cache needs to be rebuilt. But since the transaction has around 5k rows it will still save a lot of disk access when validating the FK.

We'll have to wait for Tim on this. I'm in so far over my head I can't tell up from down anymore.

Roy Lambert