> From a quick search, I suspect that will be the "pag_scn" 4 byte value.
I don't recall exactly, if you want to pursue this you should ask on the Devel list for confirmation. > That would mean that I could relatively easily write my own sync code that > could also read all those values and decide which page would need to be > transferred while the file is locked. I don't think that it will be advisable (see below), but why duplicate what nbackup is already doing? > The disadvantage would be that I would need to keep close control of these > files as nbackup could not come to help to prevent incorrect ordering while > merging... There are many other factors to consider: - backup/restore of source database using gbak -- this would reset all page "version" values - correctly detecting the database page size value -- which can be changed via gbak backup/restore. - the ODS (on disk structure) for database pages can change from version to version*. You would need to factor these changes in your own code. > Does NBackup do any other magic than that? It ensures that a backup file is being applied to the correct target database -- it does not blindly restores backup files on top of database. Sean * A change to the header layout would be part of a major ODS update. Such updates have (historically) only occurred with major Firebird releases (though this may change in the future)
