Subject Re: [firebird-support] Migrating from MySQL to Firebird
Author Helen Borrie
At 06:55 AM 16/01/2012, Go Green wrote:
>I don't want to start a comparison debate. One of my .NET application is running with MySQL back-end from the last three years. Because of some issues, I want to migrate the database to Firebird. Apart from these unforeseen issues, there is one more reason to choose firebird.

>I came to know that firebird has an option to use single file database as well.

Actually, it is not an "option". Firebird is not a file-served database engine. The entire database lives in one file by its architectural nature. An old option was (and still is) available to split that logical file up across multiple disks. It was relevant in the days when a 1 GB disk was considered "huge". But it is not possible to access these split files as "different parts". The Firebird engine controls the disk space entirely.

>This becomes data files easier to manage and backup.
>I have following queries before migration:
>How Crystal Reports (with Visual Studio 2008 and above) handles firebird connections? Is it via ODBC?

Ask about this on the firebird-net-provider list. Yes to ODBC (ask about that on the firebird-odbc-devel list) but you *might* find someone in .net arena has a way to do Crystal Reports through the ADO provider interface.

>How reliable is the single file database model

Not a relevant question.

>and what type of installation (Classic/Super Server) is recommended for this model?

Choice of server model has nothing to do with "the single file database model". It has to do with resources available on host and network and user load. You can experiment with both models since the database architecture doesn't vary according to which server model accesses it.

>What are the strong points of firebird over MySQL?

They are "apples and oranges". If you have a reasonable understanding of the architecture and functionality of MySQL, you would probably get a feeling for the (vast) differences by reading this article - a few years old now but still applicable: