>I think replication can
>solve _most_ of these problems, perhaps enhancing gbak
>could too.

Replication is not a solution if the unwanted data manipulations are simply
replicated to the other copies. Replication is a solution to either
distribute data or provide some sort of pseudo clustering/shadowing.

gbak would need the core enhancements I am talking about in order to do any
more good here.

>Adding clunky, bloated security layers to InterBase is
>not attractive to me.

Nor is it to me.

The suggestions I have made should in no way result in clunky, bloated
security layers. I'm not talking about additional security layers. I'm
talking about leveraging the MGA architecture of InterBase in such a way
that an administrator has much more control over their data. Perhaps it
increases some of the internal complexity but they seem to me to be natural
extensions to the versioning engine.

The downsides to this is that the database file would hold all of the past
information held up by a freeze point so the database may grow in size
considerably depending on the update volume. It will also impact the
transaction cycling since there would need to be the equivalent of a "stuck"
transaction. The sweeper would need to be ehanced such that it would protect
this frozen point rather than sweep it away. Not sure how this would affect
referential integrity but it could be a challenge depending on what
assumptions were made at the time the checks were made.

Both of these downsides seem entirely feasible to deal with if it would open
opportunities to use InterBase in a situation that formerly you would be
forced to use Oracle in. This is the case I am taling about...

I guess I may just have to wait and see the code...

>Just commenting.

Totally appreciated!

Jason Wharton
InterBase Developer Initiative
jwharton@...

InterBase will be the database of the new millennium.