The Decline of #MySQL and Rise of Firebird SQL

The decline will not be immediate, it will take some time, notably Apache distributions like XAMPP and WAMP will have to offer users alternatives to MySQL, as most developers use these packages, instead of installing products independently. All is not lost, the Open Source community has plenty of options. There are two well established alternatives to MySQL: PostgreSQL and Firebird. Both have large established communities, and support of major corporations. One of these will become the next MySQL

Migrating users from FB 2.1 to FB 2.5

People moving to FB 2.5.0 may be asking if it is safe to copy the security2.fdb file from previous versions of Firebird to Firebird 2.5, keeping the users previously created, so avoiding to recreate them.

In theory, copying the file should work, but with no guarantees. Firebird 2.5 uses a new ODS (11.2). You can do a backup/restore in FB 2.5 to update the ODS of security2.fdb, but some problems will still persists, regarding the use of the new role RDB$ADMIN (which gives SYSDBA rights to “normal” users) – in this case, normal users who were granted RDB$ADMIN role, will have problems to use the new SQL commands CREATE/ALTER/DROP USER. Note: Firebird 2.5.1 will bring a sql script to fix this problem.

So, the safest way to move users to FB 2.5 right now, is to recreate them in Firebird 2.5, either using gsec.exe or the new CREATE USER statement.

Thanks to Dmitry Yemanov for detailed information about the problem.

Wanna transaction in MySQL? Ok, pay now, or go to Firebird.

Looks like Oracle decided to charge money for those who wants to use InnoDB with MySQL. InnoDB offers features like transaction control, not found in the “classic” version of MySQL. Read more  here and here.

Need Transactions, Stored Procedures, Triggers, etc. and don’t wanna to pay? GO FIREBIRD!

Update: As pointed by some of our readers, InnoDB is still offered for free in the MySQL “Community” edition.

Default transaction in a #php application

By default, the transactions are IBASE_WAIT, so it waits until the record is no longer edited. You have to start a transaction with the IBASE_NOWAIT option to get an immediate response in a deadlock situation.

One example is a php application waiting for desktop app (administration tool) to finish the transaction

When I try to update a record that’s edited in a desktop app or IBexpert, and there is a deadlock, ibase_execute just hangs, does not return any value nor raises an exception.

1 2 3 4