|Subject||Re: [firebird-support] Disable / Enable Triggers|
> . transfer the data from the old database (direct transferOMG, blobs. I completely forgot about blobs...:(
> from old to new, no need for interim storage which can
> have problems handling blobs etc).
> . apply a "final" script that fully defines the triggers,Understood.
> procedures and other constraints.
I was thinking of the 'empty' database as everything else except the
data, hence the original question. Maybe separating it into the three
stages that you outlined is better for the long run.
Because firebird doesn't yet support multi database queries, i'm
resorting to exporting the data as INSERT statements, which obviously
doesn't work with BLOBs... *sigh*.
> It simply copies a database, but the concepts and procedureUnderstood. Thanks for the link. Checking it out now.
> are pretty much the same - indeed DBak can be used to do an
> upgrade with a certain amount of fiddling, because it allows
> you to split the processing and replace the database creation
> The transfer process in a real-life upgrade is not always aATM, If there are additional fields/etc on the new database, i'm
> straight forward process - since you must ensure that new
> fields are completed appropriately and any change to
> constraints is appropriately managed during transfer.
enforcing the new data via BEFORE INSERT triggers that provide default
values. This is completely different to the triggers that i wanted to be
disabled per the original question. Those triggers are mostly AFTER
> Note: In any significant upgrade I would probably add someAt this point, the 'upgrade' process is completely separate from the
> sort of validation/testing process on the end. Particularly
> if your normal backups use gbak, do a backup and restore to
> be sure that your new database can be survive a backup and
> restore cycle (that there is not some sort of data issue that
> will disrupt gbak).
normal backup/restore maintenance cycle. But i'll keep that in mind.