Even though the original article is fairly old by internet/development standards, most of the facts still stand. However, life never stands still, especially not for small agile software companies. By the end of 2001, Borland has seized any future development on the open-sourced version of Interbase. Fortunately a group of amazing developers has picked up the slack and forked the code base and in winter 2002 we have switched to Firebird 1.0 the “true” open source Interbase and the following year to Firebird 1.5.With close to 1000 deployments on various desktop and server configurations and thousands of gigabytes of data spread across all the databases, I think we can consider ourselves as seasoned Firebird users/developers.

But, as with any technology, we had our share of challenge and success stories. Following are a few items what to look for and what to look out for. Let’s start with the issues as these are most of the time the determining factor when it comes to adoption of new technology:

The Issues

Firebird is not very forgiving when it comes to sloppy SQL syntax. Things that you can get away with in SQL Server, will kill the db performance in Firebird. For instance:

Select * from SomeTable where id in (Select some_id from SomeOtherTable)

If the subselect should return a lot of records, the performance will be abysmal. Fortunately if you think outside of the box, there is always a workaround. In this case we could use a selectable stored proc to do an inner join on like this:

Select * from SomeTable inner join SelectableStoredProcedure(Params) on (someid = stored_proc_param)

Another issue that we have run into a few times is the high bandwidth requirement when transferring large blob datasets over the Ethernet. Essentially, when performing a query that returns a lot of data (lets say 100 MB) to the client, Firebird will max out the Ethernet bandwidth on a 100 Mbps switch very quickly without even making the hard drives work. SQL Server performs much better in this instance.

One feature that we sorely miss is the cross database joins that are easily done in SQL server. There are workarounds in Firebird (like defining an external table) but it’s not the same. Hopefully, this feature will be added to FB 2.0.

The Awesome

Enough of the issues, lets cover the exciting items, things that have made our lives easy:

The deployment as part of a custom setup is a breeze. With all our deployments we have had only 3 problem installations. One was caused by a faulty Ethernet card and the other two on Windows ME. I think this metric speaks for itself. In contrast, we are supporting an outside company with MSDE deployments. The failure rate is an astonishing 25% for MSDE deployments in uncontrolled environments. Most of the time these are issues that can be resolved, but the cost of support is very high.

Mentioned before, selectable stored procedures. The power of this feature becomes evident when you can do an inner or outer join between a table and a stored procedure. In addition, stored procedures work “internally” similar to cursors (there is a loop inside the stored proc) where additional programming logic can be embedded.

Firebird also works well in many environments. Currently we have a .NET project with Firebird deployment on Win2K3, VB6 projects and even Firebird running with Ruby on Rails on a Linux host.

Hopefully this little status update will be useful to somebody. What’s important that after five years, we are still sticking with Firebird and there is no change in sight…

It will also support large database files (larger then 2 gig. I know a guy that has a 300 Gig database up and running)

Anyhow, in this article I will describe the issues and the necessary tools to get you up and running with Interbase.

First let me tell you about the benefits of Interbase:

1. Open Source
2. Fast
3. Small size
4. Very easy distribution (scripts for Wise or InstallShield are available)
5. Works ADO
6. Works with ODBC
7. Awesome transaction management (readers never block writers and vice versa)
8. Multiple platform support (Linux/Unix)
9. Superb support for BLOB fields (Images and memo fields)
10. Support for Arrays (you can store Arrays in individual fields)

For starters you need to get the server and client software. You can get the original Open Source version (Source and Binaries) from Borland at:

http://www.borland.com/devsupport/interbase/opensource/
or get it a modified version (Firebird) from:
http://www.ibphoenix.com/ibp_download.html

Download and install the server and client binaries. The Interbase server ships with a ODBC driver, but I hate ODBC and use ADO/OleDB on a day to day basis. So I had to find an OleDB driver for Interbase. Luckily there are numerous available. You can find a links to download sites on this site:

http://www.interbase2000.org/tools_conn.htm

I opted for the IBProvider from http://www.lcpi.lipetsk.ru/prog/eng/index.html because they had some VB samples of how to use the provider with ADO. The version that you can download is an Evaluation for 30 days. If you want a completely free OleDB provider then use: Http://www.oledb.net/?Page=FAQ . However, all my sample code is tested with IBProvider only.

Once you have downloaded and installed all the files, you are ready for development. IB (Interbase) ships with a sample database called employee.gdb. We will use this database as an example. (You can find it in ‘C:Program FilesBorlandInterBaseexamplesDatabase’ , provided you installed the server in the default location). Anyhow, lets start with the basics:

Connecting to Interbase
Lets establish a connection to the database. A sample connection:

Dim adoConn As New ADODB.Connection

adoConn.ConnectionString = "provider=LCPI.IBProvider;data source=localhost:C:Interbase DBsEmployee.gdb;ctype=win1251;user id=SYSDBA;password=masterkey"

adoConn.Open

Ok, here are a few things to consider:
Default user name and password (like SA in SQLServer) are SYSDBA and masterkey (case sensitive). The ‘data source’ parameter has a following syntax: IP Address:file location on the remote system . If you installed the server on your development machine then use localhost or your IP. If you installed it on a remote machine then use the IP Address of the machine. The file location is a bit weird. It is local to the server and you can’t use UNC paths.

Once the connection is open, we can start working with the database.

Working with an Interbase database
For the most part, working with Interbase is as easy as working with SQL Server or Access. However there are a few things to consider:

For one, Interbase uses dialects, basically it’s the SQL syntax that you issue your commands to the database. IB 6.0 can use Dialect 1 (legacy) and Dialect 3. The sample databases are in written in Dialect 1. If you decide to use Dialect 3 (as I have), you will notice some weird behavior. If your database has lower case table and field names, you will have to surround them with double quotes. For instance: Select "CompanyName", "Address" from "tblCustomers". Needless to say this will create havoc with VB programmers J. One workaround is to use caps for table and field names. (Btw, don’t ask me why this is the way it is.) For Instance: SELECT COMPAN_YNAME, ADDRESS FROM TBLCUSTOMERS.

The other issue that I have found is: you cannot use adCmdStoredProc as your command type. Workaround for this: use adCmdText. But more to this later.

Ok, so how would we get some data in and out of our database? Well, you can use your normal recordset object to execute a SQL statement or you can use stored procedures.

Here is a sample of a simple select statement:

Dim rst As New Recordset

rst.ActiveConnection = adoConn
adoConn.BeginTrans
rst.Open
adoConn.CommitTrans

And here is a simple stored procedure execution:

Dim rst As New Recordset
Dim cmd As New ADODB.Command

adoConn.Open

With cmd
.ActiveConnection = adoConn
.CommandText = "Select * FROM DEPT_BUDGET (100)"
End With

adoConn.BeginTrans
Set rst = cmd.Execute
adoConn.CommitTrans

Notice that if your stored procedure returns any rows, you have to use the ‘SELECT * FROM stored procedure name’ syntax. If your procedure does not return any records, you can use ‘EXECUTE stored procedure name’.

Also, the way you pass parameters in and out of the procedure is a bit peculiar. Lets say you have an insert stored procedure that will accept 3 parameters. To pass those parameters you can use inline syntax: For instance, ‘execute procedure PROC_INSERT_TBLCUSTOMERS (comma delimited parameter values)’ or you can use this syntax:

With cmd
.ActiveConnection = adoConn
.CommandText = " execute procedure PROC_INSERT_TBLCUSTOMERS (?,?,?)"
End With

adoConn.BeginTrans
cmd(0) = parameter value
cmd(1) = parameter value
cmd(2) = parameter value
cmd.Execute
adoConn.CommitTrans

Anyhow, these are the basics. If you guys are interested in Interbase, I will write a 2nd part of the tutorial that will cover some advanced features like working with Images, Arrays, UDF functions and tools for Interbase. For now take a look at the sample code for this tutorial, and take a look at the sample databases that are provided by Borland.