Subject Re: connecting to an existing firebird database using new user id/pw
Author
Post date 2016-12-19T03:39Z



---In firebird-support@yahoogroups.com, <avert@...> wrote :

I think i figure out the main reason none of the stuff i saw about "grant" and "users roles" etc. etc. worked... my database file is 2.1 format.

SQL privileges have "worked" in Firebird since before Firebird even existed.  But the RDB$ADMIN role feature is not like other roles and it wasn't formally introduced until Fb 2.5.  I do seem to recall it went into a late sub-release of 2.1 at some point but don't rely on my memory (I don't!).


Once i converted it to 2.5 format, everything worked how i figured it out given what you said and i read online.

So, this brings me to one final question:

- i've got users with 50Gig Firebird DB files.  Millions and millions of records in dozens of tables.  What are the risks of doing a gbak to backup the 2.1 format db file and then restore it to a 2.5 format db file?

The big risk with a migration is sloppy work.  Don't take short cuts and don't go live with it until you have tested it satisfactorily. A 50GB migration is not a five-minute job.

is that something you'd recommend?  is there a better way to go from 2.1 FB format db file to 2.5 than to do a gbak and restore?

It's the ONLY way, unless you want to create a whole new database and pump the data. People occasionally have to do that if they have corrupted a database but it's not the recommended way to upgrade the on-disk structure.  Upgrading is one of the specialty jobs that gbak is designed for.  Do the gbak backup under the 2.1 server and restore that backup under 2.5 under completely clinical conditions, i.e., no users logged in or trying to do so during the backup or restore. That's because gbak backup runs in a snapshot transaction and backs up the state as it stands when it starts.  That's fine for your routine backups but, if you are going to use a backup for an ODS upgrade, you don't want to leave "marooned" operations behind.  During restore, gbak creates a totally new database and populates it in steps in a series of transactions.  Nobody should try to log in while a restore is in progress.

Allow plenty of time and disk space and an exit strategy in case your backup won't restore successfully under 2.5.  Do NOT overwrite your 2.1 database.  Rename it and keep it in a safe place.  Plan tests that you can perform with your application code once the restore under the 2.5 server is complete.

HB