Did you know, that you can use in Firebird .NET Data Provider more “firebirdish” connection strings?
Read more on “Firebirdish” connection strings.
The recent release of Firebird version 2.1.1 is very welcome.
Here are a few of the fixes I consider important for 2.1 production servers and so recommend the update:
The complete list of bugs fixed and the downloads are at the Firebird SQL website.
Called SuperClassic, it will be the basis for the multi-processor support that we’ll see in Firebird 3.0.
Don’t lose count. Starting from Firebird 2.5 you will be able to choose among SuperServer, ClassicServer and SuperClassic.
Basically SuperClassic is like ClassicServer. Only instead of a process for each attachment it uses a single process with a thread for each attachment. The benefit being that it uses fewer kernel resources and is a bit faster.
Read a deeper comparison between the three architectures.
In the last post I commented that I had a test-bed application, based on Apache, PHP and Firebird, and once the problem with the images was solved I could finally start doing the actual performance testing/tuning that I originally wanted to do.
The only major changes from the last post is that I’ve now upgraded the database engine to the “Firebird v2.5 Alpha 1” that supports SMP, and that the application now contains more base data in the tables.
Today, after some days/weeks, I finally created some noticable (= not only internals) progress with Entity Framework provider for Firebird.
Now, the provider is able to use, map, call, … stored procedures (and functions [very experimental]). You can select stored procedures from database, map these to some operations in EF, create “function imports” etc. You can see this working on picture:
The application was a test-bed app that uses the FireBird SQL database to handle sessions and dynamic data, all on the same machine. [Performance Tip :Seems that you need to put KeepAlive Off on apache to server many images and too many clients :If you have more clients than available apache children, KeepAlive settings will hurt overall performance and should be turned off.]
My previous post caused some very interesting discussions on the decisions that I am facing when starting on a new project. The suggestions were as varied as the choices in front of me. It seems that any of the alternatives can do the job, so why don’t I just make a decision and move on? Because its at this crucial point that any choice I make will impact the direction of the application for many years to come.
Some of you reading this may remember that back when InterBase 6.0 was released on Solaris we ran into a fundamental problem on Solaris. It seems that since 1992 there has been an open bug documenting Solaris’ file descriptor problem: “32-bit stdio routines should support file descriptors >255.”
Firebird has some funny ways of handling passwords. The maximum length of passwords that is evaluated is 8 characters. Every character after the 8th is silently ignored. That’s especially funny because the ‘default’ password for a Firebird-installation is ‘masterkey’, which has 9 characters. You can, however, successfully log in to freshly installed Firebird-servers providing the password ‘masterke’.
I’m working with Interbase and Firebird for more than four years and just now realized that when a co-worker at our company found it out while learning SQL.
The only program that I know that makes note of that is gsec, which prints a warning when setting the password to something longer than 8 characters.
http://daniel-albuschat.blogspot.com/2008/04/passwords-in-firebird.html
[ED:Daniel is working on webkit based browser named arrora ]
Looks like the Firebird team is going to put some effort on the ODBC driver, which has been lying there abandoned for a few years (last activity report is of 2006) despite it’s usefulness in windows desktop apps (at least for me ;))
