[firebird-support] Re: connecting to an existing firebird database using new user id/pw

[av...@telusplanet.net [firebird-support]]

Thanks for the information!! 

 I tried doing a gbak on 2.1 and restoring on 2.5.
 

 Small DB.
 

 Worked great.  Access seemed a lot faster too.
 

 Again, thanks.
 

 Cheers

[firebird-support] Re: connecting to an existing firebird database using new user id/pw

[hele...@iinet.net.au [firebird-support]]

 

---In firebird-support@yahoogroups.com,  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