Click here to Skip to main content
Click here to Skip to main content

MS SQL Server to FireBird migration

By , 4 Feb 2005
 

Introduction

Recently I read an article Embedded Firebird at CodeProject and decided to try FireBird. I like the idea of embedded database. FireBird allows .NET developers to put a DLL into bin directory, create database file and use usual database access. It sounds very attractive and simple in theory. So I decided to migrate from SQL Server to FireBird.

Database Creation and Tools

Embedded version of FireBird is very light, just 1.5 Mb. FireBird Data Provider for .NET is also not so big - 0.7 Mb. I downloaded all these stuffs and put required DLLs into bin directory. Then I started database creation. However, FireBird Embedded distributive does not include any tool for database administration. Well, I downloaded standard distributive (4 Mb) and installed full featured SuperServer on my workstation. I dug into Program Files in the hope of finding a DB administration tool and found one. It was an ISQL console tool. "OK, no GUI" - I thought. - "This database is for real geeks". I opened QuickStart guide, found a section about database creation and tried to create one. But, as you might guess, without success. There was strange behavior, the ISQL refused to believe me that I was really creating new database and told that database is unavailable.

Fighting with console for awhile, I decided to find a GUI tool. There were several free tools at IBPhoenix web site. First I downloaded IBSQL (1Mb). It ran, but, when I tried to create new database, showed an error "gds32.dll was not found". I hunted around and found out that original DLL could be renamed and put into the System32 directory. I started IBSQL and it worked! A new database was created!

Do you think the migration is close to completion now? Not at all. Schema importing became a really tough action. At the very beginning, I discovered that FireBird does not support IDENTITY keyword. That's not a problem, I removed it. Then things became weird. IBSQL tool did not execute query popping up the error in the line with second's table CREATE statement. I tried to correct statements and understood that the tool was unable to run several statements! There were about 40 statements to execute, and I was not very enthusiastic about doing that one by one. "Fine, let's find something more user friendly". I found FeniSQL - very light (0.5Mb) tool. The same bug! I was slightly tired of that. I found several advices in newsgroups about IBOConsole tool and got them (2Mb). Yes, this tool is really great, has appealing GUI and useful features. And has no silly restrictions on statements' execution.

SQL compatibility

However, SQL was still wrong for FireBird. I used columns named "password", "value" and "time". These are reserved keywords. MS SQL Server eats them, but not FireBird. As you understand, renaming several columns is an issue, but I want to set up database at least. So I renamed fields in schema and ran SQL script again. The database schema was created successfully.

Do you think the migration is over? I thought so in that moment, but FireBird converted all tables and columns names in upper case. And the application refused to query database correctly. Ok. Google newsgroups are helpful and I found out that names should be quoted:

CREATE TABLE "releases"
(
            "goal" VARCHAR(500),
            "finish_date" DATE,
            "start_date" DATE,
            "name" VARCHAR(150) NOT NULL,
            "project_plan_id" INTEGER NOT NULL,
            "release_id" INTEGER  NOT NULL,
             CONSTRAINT "pk_releases" PRIMARY KEY ( "release_id" )
);

I changed SQL and… Yes! I got it! I run the application and all screens seem to be working. Then I tried to add a new Project and… Yes, I got an error (I was not surprised in fact). FireBird does not support autoincremental columns. There is a workaround using Triggers and Generators. The main idea is to create generator and invoke it before insertion to increment primary key. Something like that:

CREATE GENERATOR "project_id_gen";
 
CREATE TRIGGER SET_ID FOR "projects";
BEFORE INSERT
AS BEGIN
   NEW."project_id" = GEN_ID ("project_id_gen", 1);
END

As I understand, this had to work properly. But it wasn't.

Conclusion

I spent four hours, downloaded six distributives, several times queried Google and almost resolved all problems (the keyword is almost). Well, maybe I am not a DBA guru, but have a good experience with several major databases and never encountered such difficulties with them. FireBird's behavior is illogical for me in some cases, but I am going to complete migration today. No, I am not a stubborn donkey, just because of the embedding. This way is agile and should be simple, but it is hard. That's sad.

Today I played with GENERATORS again. And (finally!) I found just one post about ID_GENERATOR problem. The solution is to create table id_generator with two fields: id (int), next (int). I created ID_GENERATOR table, changed trigger to:

NEW."project_id" = GEN_ID (ID_GENERATOR, 1);

And new Project action has been fixed. FireBird is very tricky you know...

About the author

Michael Dubakov is a leader of TargetProcess project - XP Planning and Bug Tracking Software.

License

This article has no explicit license attached to it but may contain usage terms in the article text or the download files themselves. If in doubt please contact the author via the discussion board below.

A list of licenses authors might use can be found here

About the Author

firefalcon
Belarus Belarus
Member
Lead of TargetProcess Project (www.targetprocess.com).
TargetProcess is an integrated Project Management and Bug Tracking software

Sign Up to vote   Poor Excellent
Add a reason or comment to your vote: x
Votes of 3 or less require a comment

Comments and Discussions

 
You must Sign In to use this message board.
Search this forum  
    Spacing  Noise  Layout  Per page   
GeneralThanks for sharing...memberzmariow13 Dec '07 - 10:57 
Hi,
Thanks for sharing this information. It's really helpful.
Did you take a look at sqlite?
Cheers.
QuestionHow to connect from asp.net to a firebird db on a different machinememberSumith P D11 Aug '05 - 1:55 
Hello,
Can anyone tell me the connection string to connect to a firebird database on the network machine. the db is on a different machine and I could not even connect using "Database Workbench".
Thanks

 
SAM
GeneralRight and Wrong....memberRicalawaba11 May '05 - 10:40 
I just tried Firebird for the last 3 days.
(Using usually MySQL).
 
It's true that coming from MySQL, you have to "relearn" how it works.
In particular:
- Hard to find documentation and samples ...
(I browsed their main site , and they really need to improve their documentation and samples list)
- The autoincrement isnt a feature of FireBird (and it was a so simple way with MySQL) , and with the lack of information it took me... "few hours" to get the technique (but hey... what how is "few hours" heavy when you learn something)
 
I love the Embedded Firebird Idea, in particular because I dev single user software , that need a local storage , and dont need to ask them to install a full server/client.
 
I started a tips/how-to listing thread for .NET/FireBird , it can be see there http://www.thehorde.be/modules.php?name=Forums&file=viewforum&f=39
 

GeneralI can't belive to what you wrote!memberretekmaster2 Apr '05 - 1:24 
You busy us because you spent 4 hour for migrate to another DBMS? Are you an ET? Haw much are 4 hour!! Oh my god i can't belive it..
 
Pour me..
GeneralQuotingmember61733651213 Feb '05 - 21:50 
as I'm the developer of a OR Mapping tool (www.netdataobjects.com) I've worked with quite some different SQL databases. And the first lession I learned, is to quote all names so that they can't get confused with keywords. This little trick would have saved you several hours, since two of your problems with Firebird originate in this fact. BTW: Try to generate a table with a column named "Order" in SQL Server and query a line like "select order from mytable" or "select * from mytable where order LIKE ...". You'll see the same problems.
 
Having autonumbered Id's is very comfortable, but unfortunately there are situations, where they don't work very well. Imagine a hierarchy of objects, for example, a table of contents, which you have in memory, and you want to store it. Using autonumbered Ids you have to store the top object first, then objects, which are related directly to the top object, then the next level, etc. The reason for that is: you have to get the generated Id from the database first in order to set the foreign keys correct. In this cases, it would be better to generate the Ids on the client side and store the whole bunch of data rows in once. But how can we avoid, that two concurrent clients generate the same Id? That's what sequences in Oracle and Generators in Firebird are for. A generated Id is reserved for the client, which makes the query to the Generator. And the trick is: Using increment values > 1 saves you database roundtrips, since the client needs only 1 query to the database to get, say, 10 or 100 Ids reserved.
 
I don't know, whether it is a solution for embedded databases, but using Guids as keys is a very convenient way to get rid of both autonumbered Id's and generators. With most databases, Guids are as fast as or faster than autonumbered Id's, even if we have to convert the Guids to strings, if the databases doesn't support native Guid types.
 
So it seems after all, that you not only learned about Firebird, but about SQL databases in general Smile | :) .
 

 


GeneralRe: QuotingmemberariesT16 Feb '05 - 12:04 
Tnx for the practical explanation on generators "reserved for the client" and "roundtrip savings". It's really very convinient to do it this way, performance-wise and code-wise.
 
Nobody here seems to have mentioned about FB's events and UDFs, well, especially the UDF (luv them Big Grin | :-D ). You can "extend" FB by creating your own libs of funcs using either C++ or Delphi. Fortunately, many others have contributed such libs and are available for download... for free! IMHO, migration from one rdb to another may cause some inconveniences, but the long term benefits that FB offers (other than its being free Big Grin | :-D ) outweighs the cons.
GeneralSounds just like OraclememberGX9 Feb '05 - 2:44 
I have had the same experience migrating an app from Informix to Oracle
 
once again tables and fieldname are converted to UPPERCASE, if you explicitly name a field (ie if it is a reserved word like "number") using double quotes, you always need to refer to that field/table with double quotes in Oracle.
 
Also Oracle(9i) does not have an autoincrement they use what is called a sequence object, I had to create triggers to maintain the auto increments in my App.
 
As far as embedded goes I think FirBird sounds like great solution, albeit migration might be a pain in the a$$.
 
GX
GeneralGeneratorssussAnonymous7 Feb '05 - 13:50 
Actually firefalcon, an MSSQL IDENTITY column uses the same concept as Firebird's Generators - it just provides a nicer wrapper. Firebird tends to skip on that kind of gloss, and that's why you can run it in process with very little memory. Don't give up, and definitely don't declare something hard to use when you haven't made the proper effort. There's an official reference available here:
 
http://www.ibphoenix.com/main.nfs?a=ibphoenix&page=ibp_download_documentation
 
I learned everything I needed from the Data Definition Guide and the Language Reference which are provided as PDFs on that page.
GeneralPainsussAnonymous7 Feb '05 - 4:49 
You really are no "Database guru," as you said. It sounds like you don't even know how to execute sql commands in text mode - and you don't have to be a guru (or a geek) to do that. You will learn that in a first-year database class. You didn't read the manual, and then you write an article declaring that migrating to Firebird is a pain. How about this article title: "I have no database skills and I tried to migrate to a new product without doing any research and gave up after four hours. That's a pain!"
GeneralMS-SQL to Firebird Migration GuidememberPaul Vinkenoog7 Feb '05 - 0:59 
Database migration is not a sinecure and it pays to be prepared.
 
An MSSQL-to-Firebird Migration Guide, written by Marcelo Lopez Ruiz, is available here in HTML and PDF:
 
http://www.firebirdsql.org/manual/migration-mssql.html
http://www.firebirdsql.org/pdfmanual/MSSQL-to-Firebird.pdf
 
It's a couple of yeras old but still very useful.

GeneralRe: MS-SQL to Firebird Migration GuidememberPaul Vinkenoog7 Feb '05 - 1:04 
It's a couple of yeras old but still very useful.
 
Note: one yera == approximately 365,25 Earth days.
Some people would spell this as "year" Smile | :)
QuestionBug?sussAnonymous7 Feb '05 - 0:31 
Every sql database has some features that comply to sql standard, but also lot of their own enhancements or "enhancements", and many things that are against standard. So when starting work with ANY new (to you) database, you have to invest some minimal time to study the differences, and don't just expect that anything done differently than by Bill is bug.
 
When I started to use Interbase/Firebird years ago, I found ten times more _useful_ informations about it during just one week, than after months of work with Oracle or MSsql. Big plus is also you can easily contact many Firebird developers, including the original author (Jim Starkey), who is really clever man (did you know that Interbase implemented many common (today) features before Oracle?).

GeneralQuoted & conversion tip :-)sussMartijn Tonies7 Feb '05 - 0:14 
Actually, Firebird names do not have to be quoted at all. When doing so, you are making the names case sensitive (as specified per SQL standard).
 
Using this:
 
create table "MyTable"
 
results in this:
select * from "MyTable" - fine
select * from MyTable - error
select * from MYTABLE - error
select * from "mytable" - error
 
While this:
 
create table MyTable
 
results in this:
select * from "MyTable" - error
select * from MyTable - fine
select * from MYTABLE - fine
select * from "MYTABLE" - fine
select * from mytable - fine
 

Also, when converting schemas (tables, indices etc), I can highly recommend our database tool, that supports InterBase, Firebird, MS SQL Server and MySQL: Database Workbench. Download a trial copy at http://www.upscene.com
 

GeneralMS SQL's fault - not FireBird's !memberMarc Scheuner6 Feb '05 - 1:11 
Sorry, but those issues you ran into are more MS SQL's fault since they use "enhanced" or "extended" (a.k.a. vendor-specific) features like IDENTITY and auto-increment fields which are NOT part of the basic SQL standard.
 
Oracle does the same thing in terms of GENERATORS (called SEQUENCES in Oracle) - it's MS SQL that is "odd" or special in this respect, so moving away from it might cause you some grief.
 
=============================
Marc Scheuner, Berne, Switzerland
m.scheuner - at - inova.ch
 
May The Source Be With You!
GeneralRe: MS SQL's fault - not FireBird's !memberfirefalcon6 Feb '05 - 22:57 
Yes, you are right. I just wrote about the migration.
 
Also I believe that autoincremental columns is a "good practice" (MHO).
 
Michael
http://www.targetprocess.com
XP Planning & Bug Tracking Software
GeneralRe: MS SQL's fault - not FireBird's !memberchriswa22 Mar '05 - 8:42 
I have to agree here. The "extentions" in MSSQL are not standard. I've been using Firebird for the past year and I do have to agree with the author to some extent that for me at the time is was difficult finding information. But it is there via Google. However what I did to aid in the migration was to write Perl scripts that translate the MSSQL constructs to Firebird.
 
Until I read this article I didn't know that Firebird can handle case sensitive naming. This is useful for O/R generators. I used the table names to reflect the data access object in the middle tier. Right now I merely hand correct the case insensitive naming. It would be possible to write a perl script to handle the naming but upon further reading it appears that case sensitive naming is an extension to the perferred SQL case insentive naming. Thus the best solution would be to define a data dictionary in the data base for middle tier naming transformation.
 
In addition, their is an excellent free tool for using Firebird -- IBExpert. It is a stripped down version of their excellent professional tool suite. I use the tool to verify the syntax of the sprocs. I use this in combination with Firbird's isql and command scripts. By identifying the failing script files and using IBExpert I can ascertain the failing script and correct its syntax. I use the Firebird .NET provider and NUnit to verify sproc operations. Also there is another free tool in the works called FlameRobin -- take a look.
 
Thus where I disagree with the author is that using some imagination and a little more sluthing you can easily overcome these limitations.
 
I would also suggest purchasing the excellent new book on Firebird from APRESS. Also as an FYI the Sqlserver - Firebird migration Guid incorrectly suggest using CHAR(38) for Guids as Firebird does not support guids. However the .NET provider now supports using char(16) character set octets for Guids. You'll have to write some UDF to then translate between string and char(16) character set octets -- very easy to do or check out rfunc on sourceforge.
 
For the money Smile | :) Firebird is really an excellent choice to alleviate yourself of the M$ restrictions.
 
Chris
GeneralHere is your solution:)memberUnruled Boy5 Feb '05 - 20:11 
http://www.firebirdsql.org/pdfmanual/MSSQL-to-Firebird.pdf
 
Regards,
unruledboy@hotmail.com
Generalother alternative: advantage database servermemberchristoph braendle5 Feb '05 - 3:57 
Firebird looks good, but one might also have a look at Advantage Database Server, which has similar power and is (in my opinion) very easy to use and very reliable. They call themselve to be the leanest RDBMS, and this might be true. It's not open source but it runs without a server in smaller environment for free (and very reliable too).
 
www.advantagedatabase.com

GeneralRe: other alternative: advantage database servermemberFZelle5 Feb '05 - 6:45 
Something you have to pay for is not free.
 
As much as i like that Server, it is not free.
 
If you need a real small Sql-Engine use SQLite

GeneralRe: other alternative: advantage database servermemberchristoph braendle6 Feb '05 - 2:26 
BTW, Advantage Database Local Engine is free (up to 5 users)
 
I had a look at SQLite, it's far not comparable
Generalsql2gdb toolmembergof4 Feb '05 - 22:57 
Did you try this tool:
http://www.ibphoenix.com/downloads/sql2gdb.zip
 
It helped me a lot.
GeneralOne CommentsussAnonymous4 Feb '05 - 19:24 
I don't think it will be significant easier to switch from MSSQL to Oracle or any other DBMS instead, as long as you use non-standard features heavily. So what're you complaining about?
GeneralAmen.memberPeter M. Lemmen4 Feb '05 - 12:01 
Hello,
 
Your experiences mirror mine almost exactly. I love the idea of a fully embedded sql-capable datastore, but Firebird's idiosyncracies (admittedly due to the Interbase heritage) just doesn't make it worth it. It's back to using persisted datasets for now.
 
Regards,
 
Peter.
GeneralSee alsomemberDan Letecky4 Feb '05 - 11:37 
See also the hints at http://www.dotnetfirebird.org/blog/2005/02/migration-from-microsoft-sql-to.html.
 
You need to get used to Firebird but once you know the differences it is no problem. It works great for me.
General4 Hours for a database migrations...memberColin Angus Mackay4 Feb '05 - 8:42 
That sounds great. Either your application was very small, or that the migration was very easy.
 
It was good that you've posted your experience - It gives other people a chance to see what to look out for in advance. (I'm particularly interested as I'm thinking of using Firebird for a project)
 
I've worked on a project where the SQL Server had to interact with a legacy application so everything in SQL Server had to be altered so that it would be compatible with the legacy application - there was a middleware adapter in the middle that tricked the legacy application into thinking that it was talking to a database it supported. That migration took a heck of a lot of work and broke several applications becasue they all had to change to use the slightly modified data model. Weird project - Migrating within the same database product.
 
On a more normal migration note - most databases I've worked on have tons of Stored Procedures that have to be modified to work in the new system. These tend to be the biggest problem in a migration. Also, having data-driven applications just generate their own ad hoc SQL queries and fire them at the database, because often ALL the applications have to change as well.
 

Do you want to know more?
WDevs.com - Open Source Code Hosting, Blogs, FTP, Mail and Forums

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Permalink | Advertise | Privacy | Mobile
Web02 | 2.6.130516.1 | Last Updated 4 Feb 2005
Article Copyright 2005 by firefalcon
Everything else Copyright © CodeProject, 1999-2013
Terms of Use
Layout: fixed | fluid