Scott Guthrie recently posted article about New Embedded Database Support with ASP.NET. This made me think about other options, Firebird in particular, and advantages and disadvantages. What I’m going to do is to very shortly introduce Firebird Embedded here and then compare it with features Scott wrote in his article.
Firebird Embedded, shortly, is Firebird database server in one DLL. No need to install etc., just load this DLL and use it. To be precise, there are some other DLLs, i.e. to support national charsets, but it’s still in under 10MB all. The database itself is built from same sources as “full” server and it’s not limited in any way.
Works with Existing Data APIs – as I said, Firebird Embedded is based on same codebase as “full” server, thus the SQL and API is same. And not only this, the ADO.NET provider for Firebird works with it and you’re programming using same thinking.
No Database Installation Required and Database Files are Stored on Disk – databases created by Firebird Embedded are stored wherever you want, with any extension. Firebird itself doesn’t have any master database, thus even the “full” server works with any (valid database) file.
Shared Web Hosting Scenarios Are Now Supported with SQL CE 4 – sure you don’t need to install anything with Firebird Embedded, that’s why it’s called Embedded. And not only this, from version 2.5, you can open database from different processes, i.e. IIS worker process and Apache workers or some console application doing something in background.
Visual Studio 2010 and Visual Web Developer 2010 Express Support – as the tool set for Firebird Embedded is exactly same as for “full” Firebird, you can use DDEX (aka Server Explorer support), Entity Framework (LINQ), …
Supports Both Development and Production – this is something I’m silently expecting. But yes, you can do the same with Firebird Embedded too.
Easy Migration to SQL Server – ahh, my favorite point. The Firebird Project has of course whopping number of tools to support migration from Embedded to “full”. The most used is … nothing. The databases are fully compatible and you can switch servers without any other tools, migration, conversion, … Just place it where you want it and connect to it, either with “full” or Embedded Firebird. And to switch your application? Again nothing. Same ADO.NET provider, just change connection string, if needed. Mostly you’ll add server IP address and maybe different path and manually switch server type, if you want. Really the migration is so simple. It is one minute task and thanks to same tool set, no matter what you version your targeting during development, your application will work with the other as well without any additional effort.
You like Firebird Embedded? I do, a lot. SQL Server Compact Edition 4 looks promising, but Firebird has something to offer as well. And recall, it’s based on same sources as “full” Firebird, very mature codebase, examined with tons of installations.
Firebird embedded has (had?) some limitations regarding security. It would attach any username/password combo with SYSDBA privileges if you connect in embedded mode (possibly fixed?).
That said, my life would be a lot poorer without Firebird (and so would thousands of users!!).
No, it’s still there. The reason is the embedded DLL is loaded into *your* address space, so playing with usernames/passwords is completely useless, because you can do (and screw up) anything you want there.
Is it possible to encrypt Firebird embedded?
How secure is Firebird embedded?
ad encrypt> By default no. Firebird has no such function. But you can do it yourself, as sources are freely available.
ad secure>
What you mean exactly?
Pingback: Firebird News » Firebird Embedded in comparison to SQL Server Compact Edition 4
About the encryption. Are there any ready solutions available? Or samples at least?
http://www.firebirdfaq.org/faq160/
Also RedSoft (http://www.red-soft.biz/en/index.html) has fork of Firebird with a lot of security enhancements and AFAIR ecnryption is there. Maybe you can ask them.
Thank you, I will have a look at the red-soft products…
The most used way to encript all the port messajes using ZeeBeDee: you configure it at the server to encript using a given password, then install on the clients with same password and make the work for you in the background, your app doesn’t even know about it.
http://www.firebirdsql.org/downloads/firebird_zebedee_eng.pdf
I forgot to mention: The port to encript is TCP 3050 (on the default FireBird installation) so you need to chose this port on both sides, server and client, when installing ZeeBeDe.
Sorry but firebird has a lot of other issues, one being the strange supposedly standard sql syntax variant it used, plus the .net provider is very limited.
Firebird is trying to stick to SQL standard as much as possible. Compared the syntax etc. to i.e. T-SQL, it’s much cleaner.
According to .NET provider, it’s also open source, so feel free to step in and improve something.
@Daniel: Firebird ADO.NET Provider is not limited at all. It is a wonderfull ADO.NET provider that works great on both embedded and client/server scenarios.
Hello,
can Firebird Embedded be used with Windows Phone 7?
No, it can’t.
Hi, I am planning to tryout firebird as i am having some serious network connecting issued with VistaDB.
My first concern is, whether the firebird DB file (as it is a physical file) can be attached to other Firebird server (running in any different machine) with any user / password.?
Secondly, how is the performance of firebird in network (multi-user in Windows app.) because, the network performance of VistaDB is horrible.
Can someone please throw some light on these issues?
thanks
1> Yes. As far as it’s a standard Firebird database you can use it with any Firebird user (probably sysdba) to access it.
2> I’m running Firebird on LANs without any problem and thru WANs (Internet) without any issues. The protocol has some room for improvement, but it’s not worth. Completely new, designed for i.e. Internet, would be better.
Hi,
Thanks for quick post.
>>Yes. As far as it’s a standard Firebird database you can use it with any Firebird user (probably sysdba) to access it.
Does this mean that any one can copy my Firebird database file and attach with his/her server and get access to my data and procs?
If So, is there any way to prevent this kind of activity? something like creating a user who is the owner of my database and make the data to be opened only by the same user/password combination in any machine?? (a weired guess..)
Thanks
Yes, that’s exactly like you think. You can’t avoid that, by default. But you can i.e. build your own server…
Ok, thanks
Tak Jiří, je ten Firebird opravdu tak dobrý, nebo je dobrý protože je free ?
Je dobry. Cena s tim nema co delat. Neukladal bych sva data do “neceho”, cemu neverim.
Iis it the same process of adding firebird embedded like what we do in sql server compact in vs2010 or it has different approach? Thanks in advance.
Adding to where?
I am big fan of Firebird DB, I am using it since 1.5.0 version, but I am curious why FB is not that much popular as web sites back-end DB. I would like to use embedded Firebird DB on my websites (after 2.5 version improvements), advantages are obvious (no need to install anything, all dll-s you can put in your web site bin folder and FDB in App_Data – I am using asp.net technology).
My question is: does anybody has some experiences with this approach (Medium Trust shared hosting), and what limitation I might expect? How many concurrent users can be acceptable in such scenario, are there some known issues I need to be aware of and so? Is lack of security mechanism in embedded that big disadvantage for this approach?
Thanks in advance.
I think the biggest problem will be medium trust – you’ll not be able to use fbembed.dll properly. The rest is not an issue.
Thanks for quick answer. Unfortunately, that will be an issue and I will need to reconsider my approach.