Dmitry Yemanov

Now I seem to recall the problem. Multiple options can be specified inside one `ALTER DATABASE` statement. And some of these options should not be replicated, but some others -...

This is why it's currently prohibited as a whole and replica must be re-initialized after "sensible" `ALTER DATABASE` commands.

I'd say these should be replicated: SET DEFAULT CHARACTER SET SET DEFAULT SQL SECURITY maybe also: [INCLUDE TO | EXCLUDE FROM] PUBLICATION [ENABLE | DISABLE] PUBLICATION not so sure about:...

Encryption IMHO should not be replicated, because replica security implications may be different from the master. DBA will need to re-encrypt the db after failover.

> > maybe also: [INCLUDE TO | EXCLUDE FROM] PUBLICATION ; [ENABLE | DISABLE] PUBLICATION > > IMO, this will be very useful for DBA when he changes replica DB...

> Anyway, it will be good if all options related to backup or adding secondary file will be forced to use separately. Their usage together with other options (DROP LINGER,...

> What about replicating ALTER DB partially (not all options) - there is simple solution with rebuilding SQL statement based on replicated clauses. Yes, I've already created the patch ;-)...

> > What should we do with this? ;-) > > Make ALTER DATABASE to ignore some clauses if database is in replica mode IMHO. Maybe this gonna be more...

Moved the patch into the Firebird repo: https://github.com/FirebirdSQL/firebird/tree/trace-failed-attach. @hvlad , the ball is in your court now.

> Why invent a new datatype when IStatement::openCursor() has enough room in "flags" parameter for CURSOR_PREFETCH_BLOBS flag? Client-side record is a message which format is described using BLR. If we...