Re: [firebird-support] FB1 to FB3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Sorry Carlos - I read that wrong.  Thought you were asking if the script could 
be run with isql.

Cheers,
Kevin



 

> On Apr 30, 2020, at 8:04 AM, 'Carlos H. Cantu' lis...@warmboot.com.br 
> [firebird-support]  wrote:
> 
> Step 1 is better if you are going from dialect 1 to 3, mostly due to
> the difference in the numerics internal storage.
> 
> I see no problem with any of the approaches.
> 
> I would add that, imho, step 4 in process 2 is not really necessary,
> unless you want to reset the metadata versions count of the objects
> from 1 to 0.
> 
> Also, about step 3, you can prepare a script with "create or alter"
> statements of your procedures, triggers, etc. and run it using any
> tool or even isql.
> 
> []s
> Carlos
> Migration Guide to FB 3
> http://www.firebirdnews.org/migration-guide-to-firebird-3/ 
> 
> 
> KSKSRScfs> Greetings!
> 
> KSKSRScfs> Process 1:
> KSKSRScfs> Via a script, I have successfully exported and migrated
> KSKSRScfs> all data and objects from a FB1 database to FB3.
> KSKSRScfs> Creating the objects originally had just a few errors but
> KSKSRScfs> those have been fixed and it now goes across cleanly, no errors.
> KSKSRScfs> This process has been the one most widely recommended.
> 
> KSKSRScfs> Process 2:
> KSKSRScfs> With the corrected database that goes cleanly to FB3, I tried the 
> following:
> KSKSRScfs> 1. Backup the database with FB1.
> KSKSRScfs> 2. Restore the database with FB3.
> KSKSRScfs> 3. Executed two of IB Expert’s functions: a) Recompile all
> KSKSRScfs> Procedures and b) Recompile all Triggers. (No errors)
> KSKSRScfs> 4. Performed a backup / restore with no errors.
> 
> KSKSRScfs> My question: is Process 2 an acceptable path? The only
> KSKSRScfs> reason I ask is one of my customers has many millions of
> KSKSRScfs> records and I believe Process 2 will save me a weekend of
> KSKSRScfs> work. (My next step is to benchmark how long Process 1
> KSKSRScfs> will take for this customer’s database).
> 
> KSKSRScfs> Many Thanks!
> 
> KSKSRScfs> Kevin
> 
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] FB1 to FB3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Great - thanks Mark.  I only need FR just for that, simple queries and the 
occasional update/delete sql.


 

> On Apr 30, 2020, at 9:09 AM, Mark Rotteveel m...@lawinegevaar.nl 
> [firebird-support]  wrote:
> 
> On 2020-04-30 17:42, Kevin Stanton kevin.stan...@rdb-solutions.com 
>  
> [firebird-support] wrote:
> > I always tend to do back / restores not only in this migration but on
> > a regular basis. I’m maybe a little on the paranoid side. :)
> > I have noticed some extra lines in the restore log for FB3 (this is
> > true even on a completely new FB3 database):
> > 
> > gbak:fixing views dbkey length
> > gbak:updating ownership of packages, procedures and tables
> > gbak:adding missing privileges
> > gbak:fixing system generators
> > gbak:finishing, closing, and going home
> > gbak:adjusting the ONLINE and FORCED WRITES flags
> > 
> 
> Those are just steps that gbak will apply, even if there is 'nothing to 
> fix'.
> 
> > 
> > The script is very easily generated out of IB Expert. I cannot praise
> > this tool enough.
> > 
> > I haven’t tried the script using isql but I would be surprised if it
> > didn’t work. I will give it a shot possibly over this coming weekend.
> > I’m slammed at the moment.
> > 
> > I also use FlameRobin for FB1. Not sure if that is compatible with
> > FB3? There were some concerns in previous postings.
> 
> FlameRobin works with Firebird 3, but it doesn't support the new boolean 
> datatype, and it has no support for packages and PSQL function, which 
> might incorrectly show procedures from packages, or functions. In 
> addition, user management should now be done through SQL, so the user 
> management options in FlameRobin will still work, but they will only 
> work with the first (default) UserManager. There might be some more 
> issues, but for general query work it will work fine.
> 
> Mark
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] FB1 to FB3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

I always tend to do back / restores not only in this migration but on a regular 
basis.  I’m maybe a little on the paranoid side.  :)
I have noticed some extra lines in the restore log for FB3 (this is true even 
on a completely new FB3 database):

gbak:fixing views dbkey length
gbak:updating ownership of packages, procedures and tables
gbak:adding missing privileges
gbak:fixing system generators
gbak:finishing, closing, and going home
gbak:adjusting the ONLINE and FORCED WRITES flags






The script is very easily generated out of IB Expert.  I cannot praise this 
tool enough.

I haven’t tried the script using isql but I would be surprised if it didn’t 
work.  I will give it a shot possibly over this coming weekend.  I’m slammed at 
the moment.

I also use FlameRobin for FB1.  Not sure if that is compatible with FB3?  There 
were some concerns in previous postings.


Cheers,
Kevin



 

> On Apr 30, 2020, at 8:04 AM, 'Carlos H. Cantu' lis...@warmboot.com.br 
> [firebird-support]  wrote:
> 
> Step 1 is better if you are going from dialect 1 to 3, mostly due to
> the difference in the numerics internal storage.
> 
> I see no problem with any of the approaches.
> 
> I would add that, imho, step 4 in process 2 is not really necessary,
> unless you want to reset the metadata versions count of the objects
> from 1 to 0.
> 
> Also, about step 3, you can prepare a script with "create or alter"
> statements of your procedures, triggers, etc. and run it using any
> tool or even isql.
> 
> []s
> Carlos
> Migration Guide to FB 3
> http://www.firebirdnews.org/migration-guide-to-firebird-3/ 
> 
> 
> KSKSRScfs> Greetings!
> 
> KSKSRScfs> Process 1:
> KSKSRScfs> Via a script, I have successfully exported and migrated
> KSKSRScfs> all data and objects from a FB1 database to FB3.
> KSKSRScfs> Creating the objects originally had just a few errors but
> KSKSRScfs> those have been fixed and it now goes across cleanly, no errors.
> KSKSRScfs> This process has been the one most widely recommended.
> 
> KSKSRScfs> Process 2:
> KSKSRScfs> With the corrected database that goes cleanly to FB3, I tried the 
> following:
> KSKSRScfs> 1. Backup the database with FB1.
> KSKSRScfs> 2. Restore the database with FB3.
> KSKSRScfs> 3. Executed two of IB Expert’s functions: a) Recompile all
> KSKSRScfs> Procedures and b) Recompile all Triggers. (No errors)
> KSKSRScfs> 4. Performed a backup / restore with no errors.
> 
> KSKSRScfs> My question: is Process 2 an acceptable path? The only
> KSKSRScfs> reason I ask is one of my customers has many millions of
> KSKSRScfs> records and I believe Process 2 will save me a weekend of
> KSKSRScfs> work. (My next step is to benchmark how long Process 1
> KSKSRScfs> will take for this customer’s database).
> 
> KSKSRScfs> Many Thanks!
> 
> KSKSRScfs> Kevin
> 
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] FB1 to FB3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Thankfully I moved from D1 to D3 many years ago.

So now just need to get to FB3.


Cheers,
Kevin





 

> On Apr 30, 2020, at 7:37 AM, 'Jason (PN)' ja...@jac2.co.uk [firebird-support] 
>  wrote:
> 
> Hi Kevin,
> 
> Can I ask what dialect you are going from and to?
> 
> Sorry I don’t have an opinion on P1 vs P2. Do you know why P1 is recommended 
> over P2?
> 
> As you may have guessed, I have this same thing to do 1.5.6 D1 -> ?.
> 
> Thanks,
> 
> Jason
> 
> From: firebird-support@yahoogroups.com 
>   > 
> Sent: 30 April 2020 15:23
> To: Firebird Support  >
> Subject: [firebird-support] FB1 to FB3
> 
> Greetings!
> 
> Process 1:
> Via a script, I have successfully exported and migrated all data and objects 
> from a FB1 database to FB3.
> Creating the objects originally had just a few errors but those have been 
> fixed and it now goes across cleanly, no errors. 
> This process has been the one most widely recommended.
> 
> Process 2:
> With the corrected database that goes cleanly to FB3, I tried the following:
> 1. Backup the database with FB1.
> 2. Restore the database with FB3.
> 3. Executed two of IB Expert’s functions: a) Recompile all Procedures and b) 
> Recompile all Triggers. (No errors)
> 4. Performed a backup / restore with no errors.
> 
> My question: is Process 2 an acceptable path? The only reason I ask is one of 
> my customers has many millions of records and I believe Process 2 will save 
> me a weekend of work. (My next step is to benchmark how long Process 1 will 
> take for this customer’s database).
> 
> Many Thanks!
> 
> Kevin
> 
> [Non-text portions of this message have been removed]
> 
> [Non-text portions of this message have been removed]
> 
> 
> 



[Non-text portions of this message have been removed]

[firebird-support] FB1 to FB3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Greetings!

Process 1:
Via a script, I have successfully exported and migrated all data and objects 
from a FB1 database to FB3.
Creating the objects originally had just a few errors but those have been fixed 
and it now goes across cleanly, no errors.  
This process has been the one most widely recommended.

Process 2:
With the corrected database that goes cleanly to FB3, I tried the following:
1. Backup the database with FB1.
2. Restore the database with FB3.
3. Executed two of IB Expert’s functions: a) Recompile all Procedures and b) 
Recompile all Triggers.  (No errors)
4. Performed a backup / restore with no errors.

My question:  is Process 2 an acceptable path?  The only reason I ask is one of 
my customers has many millions of records and I believe Process 2 will save me 
a weekend of work.  (My next step is to benchmark how long Process 1 will take 
for this customer’s database).


Many Thanks!

Kevin




[Non-text portions of this message have been removed]

Re: [firebird-support] Remote backup using gbak

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Mark - thank you very much!

I do want the backup file on the server so all is good there.

I have found that the spaces do cause an issue.  Where I’m at right now is the 
following:

gbak -b -user sysdba -password masterkey -service win2012server:service_mgr   
c:/~wrk/lumber.fdb/common/lumber_remote.fbk -v -y 
"/common/lumber_remote.log”

My next task is to try an alias pointing to the path with spaces.  Most of my 
installs are set up with the same folder structure, “c:\fb databases\…"


Thanks again!

Kevin







 

> On Jan 3, 2020, at 8:28 AM, Mark Rotteveel m...@lawinegevaar.nl 
> [firebird-support]  wrote:
> 
> On 02/01/2020 16:31, Kevin Stanton kevin.stan...@rdb-solutions.com 
>  
> [firebird-support] wrote:
> > The error was:
> > 
> > Gbak error: I/O error for file “c:\fbThe system cannot find file specified.”
> > Gbak error: Error while trying to open file.
> > Gbak error: The system cannot find the file specified.
> 
> Try a path without a space in it, or define an alias and use that alias 
> to connect.
> 
> Also, I think you should use
> 
> gbak -b -user sysdba -password masterkey -service 
> win2012server:service_mgr "c:/fb databases/lumber/lumber.fdb" 
> "/common/lumber_remote.fbk"
> 
> That is:
> - remove win2012server from the database path, you already specified the 
> server in the `-service`
> - use forward slash instead of backslash
> 
> However, when you create the backup this way, it will create it on the 
> server. This doesn't seem to be what you want to do.
> 
> AFAIK, Firebird 1.5 doesn't have streaming backup through the service 
> manager, so you can't make a local backup directly to the client.
> 
> Mark
> -- 
> Mark Rotteveel
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] Remote backup using gbak

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

The error was:

Gbak error: I/O error for file “c:\fbThe system cannot find file specified.”
Gbak error:  Error while trying to open file.
Gbak error:  The system cannot find the file specified.


Thanks!
Kevin


> On Jan 1, 2020, at 2:03 PM, Norman Dunbar nor...@dunbar-it.co.uk 
> [firebird-support]  wrote:
> 
> Evening Kevin,
> 
> Sadly, not-text parts of your message were removed, so we can't see "what you 
> got". Sorry.
> 
> Cheers,
> Norm.
> 
> 
> On 1 January 2020 19:23:06 GMT+00:00, "Kevin Stanton 
> kevin.stan...@rdb-solutions.com  
> [firebird-support]"  > wrote:
> Greetings!
> 
> I’m hoping someone can help me out here.  FB 1.56 (upgrading soon), trying to 
> perform a remote backup.
> 
> Here’s my batch file:
> 
> cd "c:\program files\firebird15\bin"
> pause
> gbak -b -user sysdba -password masterkey -service win2012server:service_mgr 
> "win2012server:c:\fb databases\lumber\lumber.fdb" "\common\lumber_remote..fbk"
> pause
> 
> 
> This is what I get:
> 
> 
> 
> 
> Thanks in advance!
> Kevin
> 
> 
> 
> 
> [Non-text portions of this message have been removed]
> Posted by: Kevin Stanton  >
> ++
> 
> Visit http://www.firebirdsql.org  and click the 
> Documentation item
> on the main (top) menu.  Try FAQ and other links from the left-side menu 
> there.
> 
> Also search the knowledgebases at 
> http://www.ibphoenix.com/resources/documents/ 
>  
> 
> ++
> Yahoo Groups Links
> 
> 
> 
> 
> -- 
> Sent from my Android device with K-9 Mail.. Please excuse my brevity.
> 
> 



[Non-text portions of this message have been removed]

[firebird-support] Remote backup using gbak

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Greetings!

I’m hoping someone can help me out here.  FB 1.56 (upgrading soon), trying to 
perform a remote backup.

Here’s my batch file:

cd "c:\program files\firebird15\bin"
pause
gbak -b -user sysdba -password masterkey -service win2012server:service_mgr 
"win2012server:c:\fb databases\lumber\lumber.fdb" "\common\lumber_remote.fbk"
pause


This is what I get:




Thanks in advance!
Kevin




[Non-text portions of this message have been removed]

Re: [firebird-support] A recommendation (database migration)

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

I do know that - just have never tried the cross platform yet but would love 
to.  :)



Thanks!
Kevin







 

> On Dec 2, 2019, at 11:12 AM, Karol Bieniaszewski liviusliv...@poczta.onet..pl 
> [firebird-support]  wrote:
> 
> 
> >> That’s part of the issue - I’m a Delphi guy and not sure I could get it 
> >> cross platform.
> 
>  
> Delphi is crossplatform.
> 
> It suport Windows, macOS, iOS, Android and now Linux from one codebase.
> 
>  
> Regards,
> 
> Karol Bieniaszewski
> 
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] A recommendation (database migration)

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

That’s part of the issue - I’m a Delphi guy and not sure I could get it cross 
platform.




 

> On Dec 2, 2019, at 8:51 AM, Norbert Saint Georges n...@tetrasys.eu 
> [firebird-support]  wrote:
> 
> Kevin Stanton kevin.stan...@rdb-solutions.com 
>  [firebird-support] a 
> écrit :
> > I would be happy to donate time to help in anyway I can. This is an awesome 
> > database and I can’t say enough about FB and the developers.
> 
> Hello,
> 
> Your tool would be developed in what language? and for which platform?
> 
> -- 
> Norbert Saint Georges
> http://tetrasys.fi 
> 
> 



[Non-text portions of this message have been removed]

[firebird-support] A recommendation (database migration)

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Greetings!

We are in the middle of migrating from FB 1.56 to 3.x.

Of course the recommendation is to create a script of the database and run it 
against FB 3 which we’ve done.  We’ve also purchased the Migration Guide to 
Firebird 3.

Now comes the challenge - getting the data over.  Some of our customers have 
millions and millions of records.
The recommendation is to use a tool to pump the data over.  Clever Components 
has a tool but it seems really out-dated and not very intuitive.  This tool is 
a suggestion in the Migration Guide.

I understand not having a GUI tool with Firebird as there are a few really good 
ones out there.  (IB Expert is my must-have tool)

However, I t think it’s imperative FB has a database migration tool..  We 
should not have to rely on any 3rd party tools to upgrade a database.

Here’s what I would love to see the process being:

Have a tool to analyze the current database.  This can already be done by 
creating a script and running it against the target version of FB.
Once the database is created successfully with no errors or warnings in step 1, 
all we should have to do is backup the database in the older version of FB and 
restore it in the target version.  I know triggers and stored procedures don’t 
get recompiled, but they should somehow.  I’m sure the Firebird Gurus can 
figure this one out.  :)
  

I would be happy to donate time to help in anyway I can. This is an awesome 
database and I can’t say enough about FB and the developers.


Just some thoughts here as I go through the (so-far-painful) migration process.


Best Regards,
Kevin




[Non-text portions of this message have been removed]

Re: [firebird-support] Off-Topic: Firebird future

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

That would be awesome.



> On Oct 21, 2019, at 10:29 AM, 'Alexey Kovyazin (ak)' a...@ib-aid.com 
>  [firebird-support]  > wrote:
> 
> 
> Hello Stefan,
> 
> 
> If Firebird users want to have GUI too, we should consider the options.
> The situation now is really different than several years ago, so including a 
> free GUI to Firebird umbrella now is really a option. For example, at 
> Firebird Conference there was presentation about RedExpert - GPL license, 
> multi platform, developed by contributor of Firebird and (since last week) 
> Platinum sponsor.
> I tried its beta on Linux and Windows and it worked far better than thing 
> included into Postgresql and abandoned FlameRobin.
> 
> Of course, we should discuss all aspects before making the decision. 
> 
> Regards, 
> Alexey Kovyazin 
> IBSurgeon 
> 
> 
> 
> пн, 21 окт. 2019 г., 19:24 Stefan Heymann li...@stefanheymann.de 
>  [firebird-support] 
> mailto:firebird-support@yahoogroups.com>>:
>  
> 
> > Official or not, we need a simple, up to date, Firebird only, native
> > GUI.
> 
> I don't get the point. There are GUI tools readily available
> (IBExpert, Upscene, etc.). If you want to have it for free, like in
> free beer, you can sit down, write it and publish it (that's how free
> software is made ...). The Firebird Project just doesn't have the
> resources to do it. We need the available developers for the database
> core and not for a fancy GUI tool.
> 
> Best Regards
> 
> Stefan Heymann
> 
> 
> 
> 






Thanks,
Kevin


~~~
Kevin Stanton
Software Architect
P: 541-550-5966 | F: 503-822-0178
www.RDB-Solutions.com 

 






 



[Non-text portions of this message have been removed]

Re: [firebird-support] Will we move when yahoo Groups close theirs doors?

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Oregon Delphi Users Groups has the same issue.  Looks like that group is moving 
to http://groups.io 



> On Oct 19, 2019, at 5:01 AM, Mark Rotteveel m...@lawinegevaar.nl 
>  [firebird-support] 
> mailto:firebird-support@yahoogroups.com>> 
> wrote:
> 
> On 18-10-2019 13:45, emb_blas...@hotmail.com  
> [firebird-support] wrote:
> > Recently I learned that Yahoo! will close Groups.
> 
> It looks like they are going to close the site, but the mailing list 
> feature is expected to remain online (as far as I can tell from the 
> announcement, which to be honest isn't very clear).
> 
> > We will lose all the content?
> 
> If the site closes, yes. However, I have created a backup of the 
> messages from firebird-support, firebird-php, firebird-python, 
> firebird-java, ibobjects and ib-conversions, and I'm currently looking 
> at generating a basic accessible archive.
> 
> I don't have backups for firebird-general, firebird-coredocs and 
> firebird-architect, as those seem to be closed groups, and the tool I 
> wrote for the other groups isn't working. I probably need to add some 
> authentication, but I haven't tried that yet.
> 
> Mark
> -- 
> Mark Rotteveel
> 
> 






Thanks,
Kevin


~~~
Kevin Stanton
Software Architect
P: 541-550-5966 | F: 503-822-0178
www.RDB-Solutions.com 

 






 



[Non-text portions of this message have been removed]

Re: [firebird-support] Migrating from 1.56 to FB 3 - making good progress

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Thanks Carlos - I have been reading your book - it’s been a great help.  I need 
to refresh myself with it though.
Kevin








 

> On Oct 2, 2019, at 10:53 AM, 'Carlos H. Cantu' lis...@warmboot.com.br 
> [firebird-support]  wrote:
> 
> I guess you can just extract the Procedures and Triggers DDL in
> IBExpert, with the option of using "CREATE OR ALTER", and run it in
> the restored DB.
> 
> If you have more doubts about the migration process, you may wish to
> take a look at my Migration Guide to FB 3 eBook at
> https://www.firebirdnews.org/migration-guide-to-firebird-3 
> 
> 
> Carlos
> www.firebirdnews.org  - www.FireBase.com.br 
> 
> 
> KSKSRScfs> Cool. I will try the IB Expert Data Export feature first
> KSKSRScfs> on the new/empty FB3 database.
> 
> KSKSRScfs> If I have to recompile all objects, is there an “easy” way to do 
> this?
> 
> KSKSRScfs> Thanks!
> KSKSRScfs> Kevin
> 
> KSKSRScfs>  
> 
> >> On Oct 2, 2019, at 10:24 AM, 'Carlos H. Cantu' lis...@warmboot.com.br 
> >>  [firebird-support] 
> >>  >> > wrote:
> >> 
> >> KSKSRScfs> My question:
> >> KSKSRScfs> Now that my 1.56 metadata script works w/out error with
> >> KSKSRScfs> the 3.0 database, can I simply backup the 1.56 database and 
> >> restore under FB 3?
> >> 
> >> In theory, yes. But note that the BLR of existing objects (procedures,
> >> etc) are not recompiled when you do a restore, so, maybe you would
> >> like to recreate all the procedures, triggers, etc. after restoring
> >> the database to be sure that they are recompiled in FB 3.
> >> 
> >> Vlad said to me that there are some benefits of recompiling the
> >> objects in FB 3: New engine could use new blr, also it will create
> >> "debug info" for sp\triggers - it allows to produce error messages
> >> with line numbers in call stack.
> >> 
> >> []s
> >> Carlos
> >> https://www.firebirdnews.org/migration-guide-to-firebird-3/ 
> >>  
> >>  >> >
> >> 
> >> KSKSRScfs> Greetings!
> >> 
> >> KSKSRScfs> I have been successfully created a script of the metadata
> >> KSKSRScfs> in the 1.56 database, ran the script against FB 3 (all using IB 
> >> Expert).
> >> 
> >> KSKSRScfs> Initial attempt only revealed about 20 or so errors. Not
> >> KSKSRScfs> too bad for a fairly complex 20-year old database.
> >> 
> >> KSKSRScfs> I have fixed all the errors and can now run the script with no 
> >> warnings or errors.
> >> 
> >> KSKSRScfs> The trick is populating the 3.0 database. I know there
> >> KSKSRScfs> are data pump tools out there but they seem to be old?
> >> 
> >> KSKSRScfs> My question:  
> >> KSKSRScfs> Now that my 1.56 metadata script works w/out error with
> >> KSKSRScfs> the 3.0 database, can I simply backup the 1.56 database and 
> >> restore under FB 3?
> >> 
> >> KSKSRScfs> Thanks in advance!
> >> 
> >> KSKSRScfs> Kevin
> >> 
> >> 
> >> 
> 
> KSKSRScfs> [Non-text portions of this message have been removed]
> 
> KSKSRScfs> 
> KSKSRScfs> Posted by: Kevin Stanton  >
> KSKSRScfs> 
> 
> KSKSRScfs> ++
> 
> KSKSRScfs> Visit http://www.firebirdsql.org  and 
> click the Documentation item
> KSKSRScfs> on the main (top) menu. Try FAQ and other links from the left-side 
> menu there.
> 
> KSKSRScfs> Also search the knowledgebases at
> KSKSRScfs> http://www.ibphoenix.com/resources/documents/ 
>  
> 
> KSKSRScfs> ++
> KSKSRScfs> 
> 
> KSKSRScfs> Yahoo Groups Links
> 
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] Migrating from 1.56 to FB 3 - making good progress

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Cool.  I will try the IB Expert Data Export feature first on the new/empty FB3 
database.

If I have to recompile all objects, is there an “easy” way to do this?

Thanks!
Kevin



 

> On Oct 2, 2019, at 10:24 AM, 'Carlos H. Cantu' lis...@warmboot.com.br 
> [firebird-support]  wrote:
> 
> KSKSRScfs> My question:
> KSKSRScfs> Now that my 1.56 metadata script works w/out error with
> KSKSRScfs> the 3.0 database, can I simply backup the 1.56 database and 
> restore under FB 3?
> 
> In theory, yes. But note that the BLR of existing objects (procedures,
> etc) are not recompiled when you do a restore, so, maybe you would
> like to recreate all the procedures, triggers, etc. after restoring
> the database to be sure that they are recompiled in FB 3.
> 
> Vlad said to me that there are some benefits of recompiling the
> objects in FB 3: New engine could use new blr, also it will create
> "debug info" for sp\triggers - it allows to produce error messages
> with line numbers in call stack.
> 
> []s
> Carlos
> https://www.firebirdnews.org/migration-guide-to-firebird-3/ 
> 
> 
> KSKSRScfs> Greetings!
> 
> KSKSRScfs> I have been successfully created a script of the metadata
> KSKSRScfs> in the 1.56 database, ran the script against FB 3 (all using IB 
> Expert).
> 
> KSKSRScfs> Initial attempt only revealed about 20 or so errors. Not
> KSKSRScfs> too bad for a fairly complex 20-year old database.
> 
> KSKSRScfs> I have fixed all the errors and can now run the script with no 
> warnings or errors.
> 
> KSKSRScfs> The trick is populating the 3.0 database. I know there
> KSKSRScfs> are data pump tools out there but they seem to be old?
> 
> KSKSRScfs> My question:  
> KSKSRScfs> Now that my 1.56 metadata script works w/out error with
> KSKSRScfs> the 3.0 database, can I simply backup the 1.56 database and 
> restore under FB 3?
> 
> KSKSRScfs> Thanks in advance!
> 
> KSKSRScfs> Kevin
> 
> 
> 



[Non-text portions of this message have been removed]

[firebird-support] Migrating from 1.56 to FB 3 - making good progress

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Greetings!

I have been successfully created a script of the metadata in the 1.56 database, 
ran the script against FB 3 (all using IB Expert).

Initial attempt only revealed about 20 or so errors.  Not too bad for a fairly 
complex 20-year old database.

I have fixed all the errors and can now run the script with no warnings or 
errors.

The trick is populating the 3.0 database.  I know there are data pump tools out 
there but they seem to be old?


My question:  
Now that my 1.56 metadata script works w/out error with the 3.0 database, can I 
simply backup the 1.56 database and restore under FB 3?


Thanks in advance!

Kevin

[Non-text portions of this message have been removed]

[firebird-support] Transactions

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Greetings,

I’m sure this has been asked before - is there a knowledge base somewhere?

I’m trying to get a handle on transactions from gstat and I just want to make 
sure I’m reading this correctly.  One of my installs is having some issues, 
Firebird 1.56, Classic Server.  I have been reading Helen’s book, Chapter 25 - 
Overview of Transactions.

My app (a large one) is written in Delphi, using Devart’s IBDAC components.

Also, my end users tend to End Task on my app if a report doesn’t pop up 
immediately.  I’ve tried to educate them.  So with Classic (or Superserver I’m 
guessing) when the user kills a client app, I’m assuming it leaves not only a 
connection to the database active (as seen in Task Manager on the server) but 
also potentially one or more transactions active.


It appears from the book that I should be concerned with the gap between the 
OIT and the OAT and making sure they both move ahead.  So from the gstat 
figures below, my app needs a bunch of improvements in transaction handling 
which I’m diving into as we speak.


4/1/2019 - before backup / restore
Oldest transaction  1388(OIT)
Oldest active   812976  (OAT)
Oldest snapshot 811580
Next transaction905141
Note:  Performance was horrible on this day and usually is the first day of the 
month.


4/1/2109 - after backup / restore:
Oldest transaction  1294
Oldest active   1295
Oldest snapshot 1295
Next transaction1298
Note:  This looks perfect to me.


4/2/2019 - around mid-day:
Oldest transaction  1297
Oldest active   1298
Oldest snapshot 1295
Next transaction56071
Note:  Not good.  OIT and OAT not moving forward.

4/2/2019 - around end of day:
Oldest transaction  1297
Oldest active   1298
Oldest snapshot 1295
Next transaction91583
Note:  Even worse.  OIT and OAT not moving forward.

4/2/2019 - after backup and sweep:
Oldest transaction  1626
Oldest active   91623
Oldest snapshot 91623
Next transaction91631
Question:  I would’ve thought performing a sweep would’ve not only done garbage 
collection but also dealt with rolled-back transactions and remove “stumps” of 
deleted records (from the book) increasing the OIT.

4/2/2019 - after a 2nd sweep:
Oldest transaction  91631
Oldest active   91623
Oldest snapshot 91623
Next transaction91632
Note:  Now this is interesting.  This looks pretty perfect to me.  
Questions:  Why didn’t the first sweep give me this kind of result?  And should 
I schedule two sweeps every night?  


Thanks in advance for any help here!


Best Regards,
Kevin


Some more background:


Batch file that does backup / sweep every night:

del "e:\fb databases\lumber\lumber_bu.log"
gbak -b -user SYSDBA -password masterkey "127.0.0.1:e:\fb 
databases\lumber\lumber.fdb" "e:\fb databases\lumber\lumber.fbk" -v -y "e:\fb 
databases\lumber\lumber_bu.log"
gfix -sweep -user sysdba -password masterkey "127.0.0.1:e:\fb 
databases\lumber\lumber.fdb"


Sweep batch file I run interactively:
e:
cd "e:\program files (x86)\firebird15\bin\"
gfix -sweep -user sysdba -password masterkey "127.0.0.1:e:\fb 
databases\lumber\lumber.fdb"
pause



[Non-text portions of this message have been removed]

Re: [firebird-support] Stored procedure stops functioning correctly after restore under Firebird 3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Thank you!  Thankfully I made the dialect 1 to 3 conversion years ago.

I will check these out.  It will be a bit before I can devote 100% on this.




 

> On Feb 13, 2019, at 1:03 PM, FSPAPA INCA Team i...@foodstuffs-si.co.nz 
> [firebird-support]  wrote:
> 
> 
> Hi Kevin – I’ve had good results using fbclone to migrate from InterBase 
> 7.5.1 to Firebird 3 using this method.  Migrating from 1.5 might not be too 
> dissimilar.
> 
> https://github.com/zedalaye/fbclone 
>  
> 
> I made a couple of changes to support dialect 1 (we’re going to switch to 
> dialect 3 and remove legacy UDFs etc after our migration is complete) and 
> reverse migration.
> 
> https://github.com/stevedrake/fbclone 
> https://github.com/stevedrake/uib 
>  
> 
>  
> 
>  
> 
> From: firebird-support@yahoogroups.com 
>   > 
> Sent: Thursday, 14 February 2019 6:30 AM
> To: Firebird Support  >
> Subject: Re: [firebird-support] Stored procedure stops functioning correctly 
> after restore under Firebird 3
> 
>  
> 
>   
> 
> Thanks Mark. I realize it’s a huge migration. I will be exhaustively testing 
> everything. I like the idea of creating an empty database and pumping the 
> data over. Is there a tool for this? (Actually just found one from Clever 
> Components)
> 
> I have looked at the migration docs for the 2.x versions and will do more..
> 
> Do you think it’s worth me going to 2.5 first or go directly to 3..0? Both 
> will be a ton of work so I’m thinking directly to 3.0.
> 
> Thanks again!
> Kevin
> 
> > On Feb 13, 2019, at 9:05 AM, Mark Rotteveel m...@lawinegevaar.nl 
> >  [firebird-support] 
> >  > > wrote:
> > 
> > On 13-2-2019 16:58, Kevin Stanton kevin.stan...@rdb-solutions.com 
> >  
> >  > > 
> > [firebird-support] wrote:
> > > I’m starting to look into migrating from 1.56 to either 2..5 or directly 
> > > to 3.0. I’ve bought the Migration Guide but haven’t read it yet.
> > > 
> > > It concerns me that I would/will have to recompile all SPs and triggers. 
> > > Is there an automated way to do this? I have 909 SPs and 785 triggers. 
> > > This will be one heck of a task with my installation base.
> > 
> > The choice is to either carefully and exhaustively verify if all your 
> > stored procedures and triggers continue to work correctly, and only 
> > recreate those that you know need it, or recreate the whole shebang (you 
> > will still need to carefully and exhaustively verify them).
> > 
> > Firebird itself has no way to recreate stored procedure and triggers 
> > automatically, although it is possible to craft scripts that rebuild it 
> > based on the database metadata (assuming the source blobs haven't been 
> > cleared). I would recommend against doing that automatically and instead 
> > you should use known good and verified scripts for the actual upgrade, 
> > if only to avoid running into issue with things that are now no longer 
> > syntactically valid or unquoted use of identifiers that are now reserved 
> > words.
> > 
> > Some people advocate that you shouldn't upgrade a database at all, but 
> > instead recreate it and pump the data over. In a situation with a lot of 
> > deployments that might also fix problems with diverging structure (but 
> > if that is the case, the migration path will be more prone to errors).
> > 
> > Especially when taking the big step from 1.5, it might make sense to 
> > take it as an opportunity to improve your database design, and get rid 
> > of things that are no longer needed (eg use built-in functions instead 
> > of UDFs, switch from dialect 1 to dialect 3 if you are still on dialect 
> > 1), etc. and then migrate the data from the old to the new.
> > 
> > Firebird 1.5 to 2.0 was already a big step with a lot of new features, 
> > but also some breaking changes, sometimes subtle, sometimes not. Don't 
> > expect going from 1.5 to be simply backing up and restoring, especially 
> > not with 909 stored procedures and 785 triggers, and more so if you use 
> > a lot of UDFs, or relied on some of the ambiguous behavior that is no 
> > longer valid, used unquoted identifiers that are now reserved words, etc.
> > 
> > And realize that Firebird 2.0 was released 12 years ago. A lot of 
> > migration knowledge from 1.5 to 2.0 may have been forgotten since (or at 
> > best not easily recalled). You should really carefully study the 2.0, 
> > 2.1, 2.5 and 3.0 release notes and the Firebird 2 installation and 
> > migration guide, and as you bought it, Carlos' Migration Guide to 
> > Firebird 3.
> > 
> > Mark
> > -- 
> > Mark Rotteveel
> > 
> > 
> 
> 

Re: [firebird-support] Stored procedure stops functioning correctly after restore under Firebird 3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Thanks Mark.  I realize it’s a huge migration.  I will be exhaustively testing 
everything.  I like the idea of creating an empty database and pumping the data 
over.  Is there a tool for this?  (Actually just found one from Clever 
Components)

I have looked at the migration docs for the 2.x versions and will do more.

Do you think it’s worth me going to 2.5 first or go directly to 3.0?  Both will 
be a ton of work so I’m thinking directly to 3.0.

Thanks again!
Kevin



 

> On Feb 13, 2019, at 9:05 AM, Mark Rotteveel m...@lawinegevaar.nl 
> [firebird-support]  wrote:
> 
> On 13-2-2019 16:58, Kevin Stanton kevin.stan...@rdb-solutions.com 
>  
> [firebird-support] wrote:
> > I’m starting to look into migrating from 1.56 to either 2.5 or directly to 
> > 3.0. I’ve bought the Migration Guide but haven’t read it yet.
> > 
> > It concerns me that I would/will have to recompile all SPs and triggers.. 
> > Is there an automated way to do this? I have 909 SPs and 785 triggers. This 
> > will be one heck of a task with my installation base.
> 
> The choice is to either carefully and exhaustively verify if all your 
> stored procedures and triggers continue to work correctly, and only 
> recreate those that you know need it, or recreate the whole shebang (you 
> will still need to carefully and exhaustively verify them).
> 
> Firebird itself has no way to recreate stored procedure and triggers 
> automatically, although it is possible to craft scripts that rebuild it 
> based on the database metadata (assuming the source blobs haven't been 
> cleared). I would recommend against doing that automatically and instead 
> you should use known good and verified scripts for the actual upgrade, 
> if only to avoid running into issue with things that are now no longer 
> syntactically valid or unquoted use of identifiers that are now reserved 
> words.
> 
> Some people advocate that you shouldn't upgrade a database at all, but 
> instead recreate it and pump the data over. In a situation with a lot of 
> deployments that might also fix problems with diverging structure (but 
> if that is the case, the migration path will be more prone to errors).
> 
> Especially when taking the big step from 1.5, it might make sense to 
> take it as an opportunity to improve your database design, and get rid 
> of things that are no longer needed (eg use built-in functions instead 
> of UDFs, switch from dialect 1 to dialect 3 if you are still on dialect 
> 1), etc. and then migrate the data from the old to the new.
> 
> Firebird 1.5 to 2.0 was already a big step with a lot of new features, 
> but also some breaking changes, sometimes subtle, sometimes not. Don't 
> expect going from 1.5 to be simply backing up and restoring, especially 
> not with 909 stored procedures and 785 triggers, and more so if you use 
> a lot of UDFs, or relied on some of the ambiguous behavior that is no 
> longer valid, used unquoted identifiers that are now reserved words, etc.
> 
> And realize that Firebird 2.0 was released 12 years ago. A lot of 
> migration knowledge from 1.5 to 2.0 may have been forgotten since (or at 
> best not easily recalled). You should really carefully study the 2.0, 
> 2.1, 2.5 and 3.0 release notes and the Firebird 2 installation and 
> migration guide, and as you bought it, Carlos' Migration Guide to 
> Firebird 3.
> 
> Mark
> -- 
> Mark Rotteveel
> 
> 



[Non-text portions of this message have been removed]

Re: [firebird-support] Stored procedure stops functioning correctly after restore under Firebird 3

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

I’m starting to look into migrating from 1.56 to either 2.5 or directly to 3.0. 
 I’ve bought the Migration Guide but haven’t read it yet.

It concerns me that I would/will have to recompile all SPs and triggers.  Is 
there an automated way to do this?  I have 909 SPs and 785 triggers.  This will 
be one heck of a task with my installation base.

Thanks,
Kevin




 

> On Feb 13, 2019, at 7:39 AM, Mark Rotteveel m...@lawinegevaar.nl 
> [firebird-support]  wrote:
> 
> I can reproduce it (Firebird 2.5.8 to Firebird 3.0.4).
> 
> I suggest that you create a ticket in the tracker. The problem doesn't 
> sound familiar to me, and if it is a known problem, the core developers 
> will close appropriately to an existing duplicate.
> 
> Looking at the BLR (using set blob all in isql) and then selecting the 
> BLR from RDB$PROCEDURES does show some differences (after recreating the 
> procedure in Firebird 3):
> 
> --- v25blr.txt 2019-02-13 16:33:58.530790700 +0100
> +++ v30blr.txt 2019-02-13 16:33:48.811658200 +0100
> @@ -18,6 +18,8 @@
> blr_parameter2, 0, 0,0, 1,0,
> blr_field, 0, 2, 'P','K',
> blr_end,
> + blr_begin,
> + blr_start_savepoint,
> blr_store,
> blr_relation, 7, 'T','A','B','L','E','T','O', 2,
> blr_begin,
> @@ -35,14 +37,14 @@
> blr_parameter2, 0, 0,0, 1,0,
> blr_end,
> blr_cast, blr_float,
> - blr_value_if,
> - blr_missing,
> + blr_coalesce, 2,
> blr_field, 1, 6, 
> 'A','M','O','U','N','T',
> blr_literal, blr_long, 0, 0,0,0,0,
> - blr_field, 1, 6, 
> 'A','M','O','U','N','T',
> blr_null,
> blr_field, 2, 6, 'A','M','O','U','N','T',
> blr_end,
> + blr_end_savepoint,
> + blr_end,
> blr_end,
> blr_end,
> blr_end,
> 
> My bet is on the addition of the savepoint.
> 
> I'm not sure if this is fixable during a restore. Recompiling stored 
> procedures, triggers, etc is always a good thing to do when upgrading.
> 
> Mark
> 
> On 13-2-2019 14:57, david.holli...@parcelperfect.com 
>  [firebird-support] 
> wrote:
> > When migrating from Firebird 2.5 to Firebird 3 we have a number of stored
> > procedures that stop functioning correctly. They start working again once
> > the procedures have been rebuilt from script.
> > The procedures all perform something along the lines of inserting a record
> > with a default value and then copying this record to a different table.
> > 
> > The copy (insert) fails with:
> > 
> > validation error for column "TABLETO"."AMOUNT", value "*** null ***"
> > 
> > 
> > Simple script to reproduce:
> > 
> > CREATE TABLE TABLETO (
> > PK INTEGER NOT NULL,
> > AMOUNT FLOAT DEFAULT 0.00 NOT NULL,
> > PRIMARY KEY(PK));
> > 
> > CREATE TABLE TABLEFROM (
> > PK INTEGER NOT NULL,
> > AMOUNT FLOAT DEFAULT 0.00 NOT NULL,
> > PRIMARY KEY(PK));
> > 
> > SET TERM ^;
> > CREATE PROCEDURE TESTCOPY (PK INTEGER)
> > AS BEGIN
> > INSERT INTO TABLEFROM(PK) VALUES (:PK);
> > INSERT INTO TABLETO (PK, AMOUNT) VALUES (:PK, (SELECT
> > COALESCE(AMOUNT, 0) FROM TABLEFROM WHERE PK = :PK));
> > END ^
> > 
> > 
> > 
> > Steps to reproduce:
> > 
> > - Create new database under Firebird 2.5
> > - Run sample script
> > - Back up the database
> > - Restore database under Firebird 3
> > - Run command "execute procedure testcopy(1);" via isql
> > 
> > Versions:
> > Firebird 2.5.8
> > Firebird 3.0.4
> > 
> > Is this a known issue or bug?
> 
> -- 
> Mark Rotteveel
> 
> 



[Non-text portions of this message have been removed]

[firebird-support] Tools for finding lock conflicts

[Kevin Stanton kevin.stan...@rdb-solutions.com [firebird-support]]

Greetings,

What is the best way to track down a lock conflict on no-wait transaction 
error?  Are there any tools available?

Thanks in advance!

Kevin