Subject Re: Synchronize security2.fdb
Author Adam
> I asked about another switch - they hate switches.

From memory the behaviour you were suggesting was to do with
(NULL=NULL) returning true like some other non standard DBMS do.

The reason Ann (I think) gave was that switches provide a place for
bugs to hide, which is true.

The switch I was suggesting is no worse than ExternalFileAccess or
UdfAccess. It would be very simple to build a test case for both
possible settings of the switch. The only possible bugs that could be
introduced (boy is this not setting ones self up with an open mouth
and their foot), are that access to the security database that should
be blocked is allowed and vice versa.

> restore to another database doesn't tell you what's new. you'd also
have to
> have triggers in the security database to insert into the changes table.
> It's no less a lowering in security than the other ways I suppose to
have a
> copy of security2.fdb lying around on the server...
> adding a backup/restore cycle to the replication cycle is more
overhead but
> as you say - it's not all that dynamic.

and lets not forget that it isn't that big a database either.