Hello,

it's a long time I have been subscribed to a Firebird mailing list. So hello again, especially to Helen who always helped me years ago.

Here are several hours worth of work, which I'd really like to check you out. As I watched the progress of my favorite RDBMS Firebird, I was saddened by the fact that the embedded version is no longer a single-file deployment. Unnecessary dependencies, most of all msvcrx.dll (seriously guys, that's fine for the server version where dozens of applications share that library, but for a single embedded library?). I've read support tickets on how that isn't an issue because so many other applications use the MSVCRT libraries, but again, the official installer, which, if I remember correctly, would be required instead of simply shipping the DLLs just pukes all its installations files into C:\ without cleaning up afterwards. As only a fraction of the functionality is required, distributing about 1 MB in libraries is also overkill. It's also a tiny bit faster with static linkage, but I don't think that's of any significance.

The second, not-so-obvious dependency are the ICU libraries. I took the time to not only make all components statically linked to MSVCRT, but also made ICU to compile into static libraries and link against them, which is no easy feat. This should be a temporary remedy for CORE-2243 and CORE-1720. So basically, fbembed.dll only depends on default windows libraries like Winsock and Kernel32. There is also a folder with the lib-files required to statically link a native binary directly to Firebird. You'll still require the header files from the official Firebird Embedded release to use them, but at least you won't be needing an external DLL. MSVSC9 was used to compile all binaries.

As an additional bonus, I combined the native fbembed.dll with the current ADO.NET driver into a single native/managed DLL, which can be referenced in any .NET Project. A small example file is included. Obviously, Firebird will not be able to format error messages without firebird.msg, so I'd really like to see that small file go into a resource of one of the DLLs and/or executables. This obviously would require source changes, at least a conditional statement checking for the existence of the messages as a resource and a fallback to the external file. I'm not in the position to make such changes, at least not globally.

The idea behind the whole thing is having a single EXE-file deployment. There are cases where this doesn't matter at all, and there are cases where it is very important to only have a single file distributed which contains all functionality. I often pack .NET projects into single assemblies because it makes deployment much easier. Having a full-featured, SQL-compliant database server as an embedded version available in client applications makes things so much easier, and as we all know, the only real alternative, SQLite, is nice, but no match to Firebird's speed and feature set.

You can download the current version here, currently it's 32 bit only:
http://graef.cc/Store/FB-Embedded-Static-2.5.1.26351-0.zip

Regards, Alexander Gräf