Hi, i am really surprised – why reinvent the wheel? All people use table with version information and this work years. Table have benefit – you can include version description (what’s new).
At application start or installer – you check if db is up to date or if instaler is not older than database itself. If db is older then do backup and restore and try to patch it with new script. If all are succesfull then update version info. If not, then mark it as broken. regards, Karol Bieniaszewski From: mailto:firebird-support@yahoogroups.com Sent: Friday, December 04, 2015 6:07 PM To: firebird-support@yahoogroups.com Subject: Re: [firebird-support] Is it save to append some data at end of the binary firebird database file? Fabiano Kureck suggested sticking application version information in the checksum slot of the page header. Mark Rotteveel quite correctly responded. That is very dangerous to do, the same bytes might be reused differently in a newer ODS. Either use a normal Firebird table to store version info, or do it outside of the database. Do not hack things in the internal structure. The page header is not a good place to stick information. It does change to support new features. However, the database header page has a place that you might be able to use. The format of the header page is defined in ods.h. The first part is fixed. The second part is a string of "clumplets" which are groups of attribute-length-data triplets. By design, Firebird skips over clumplets it doesn't understand. You could write a program that adds a new clumplet of a type undefined by Firebird to hold your version information. It wouldn't survive a gbak backup/restore cycle. The discussion was about finding portable mechanism to identify the application version of a database. Are you aware that databases are not portable across machines with different endian characteristics? Good luck, Ann ------------------------------------------------------------------------------
