What is “the” Firebird package to use today? FDB? pyFirebirdSQL? kInterbasDB?

Short answer is FDB
The difference between FDB and kInterbasDB is explained here

It’s old and unmaintained , all effort is on FDB driver and it is backward compatible with kInterbasDB
Now between FDB and FirebirdSQL , from what i know pyFirebirdSQL is pure python so it can work without any other so/dll installed and it can be used for example in places where there is no Firebird client installed (think of android python script)

Django 1.4 support for Firebird ready for tests

Maximiliano Robaina wrote on django-firebird group

I would just like to say that the first attempt to support django 1.4 is ready for test, but we have a few considerations related to this release.

First, this test version live in  github.com/maxirobaina/django-firebird
For now, this repo is just for test but I think that will be the next official home in short time.

Second, the way as insert worked was deprecated. At previous versions we have contemplated not to use triggers for manage auto incremental fields, the value of autoinc fields were generated on python code by using GEN_ID or NEXT VALUE FOR according to firebird version. Now, is necessary to have triggers (and sequences/generators) for inserts and set new primary key values, then, if you are using a legacy database without this, It will not work.
If anybody think that is a bad idea remove this behavior and need it, we can discuss about it.

Third, obviously django-firebird doesn’t pass all the django test suite.
For example, django try to create a field as decimal(38,30)

django.db.utils.DatabaseError: (-842, u’isc_dsql_prepare: \n  Dynamic SQL Error\n  SQL error code = -842\n  Precision must be from 1 to 18 — CREATE TABLE “MODEL_FIELDS_BIGD” (\n    “ID” integer NOT NULL PRIMARY KEY,\n    “D” decimal(38, 30) NOT NULL\n)\n;’)

And of course, we need to have our own test suite.

That is all. Feel free to try and to express your opinion.

Jaybird 2.2 #JDBC #Java driver is Released with many fixes

The Firebird JDBC team is happy to announce the release of Jaybird 2.2.0.

This release contains the following changes:

  • Enhanced support for JDBC 4.0 (Java 6)
  • Support for JDBC 4.1 (Java 7) — including try-with-resources support,
  • Implementation of getGeneratedKeys(),
  • Enhanced support for the services API,
  • Support for 64 bit native libraries for Type 2 / Embedded,
  • A number of bug fixes.

Fixes since Jaybird 2.2.0-beta-1:
* ConcurrentModificationException when closing connection obtained from org.firebirdsql.ds.FBConnectionPoolDataSource with statements open (JDBC-250),
* Memory leak when obtaining multiple connections for the same URL (JDBC-249),
* CPU spikes to 100% when using events and Firebird Server is stopped or unreachable (JDBC-232),
* Events do not work on Embedded (JDBC-247),
* Provide workaround for characterset transliteration problems indatabase filenames and other connection properties (JDBC-253),
* FBBackupManager does not allow 16kb page size for restore (JDBC-255),
* Log warning and add warning on Connection when no explicit connectioncharacter set is specified (JDBC-257).

The release is also available on maven(*):

<groupId>org.firebirdsql.jdbc</groupId>
<artifactId>jaybird-jdkXX</artifactId>
<version>2.2.0</version>

The artifactId depends on your target Java version: jaybird-jdk15, jaybird-jdk16 or jaybird-jdk17.

Wiped out the legacy compatibility option OldSetClauseSemantics in Firebird 3.0

The option in the config is removed

 

Prior to Firebird 2.5 the SET clause of the UPDATE statement assigned columns in the user-defined order with the NEW column values being immediately accessible to the subsequent assignments. This did not conform to the SQL standard. Starting with Firebird 2.5, only OLD column values are accessible to all the assignments of the SET clause.

Example of the old vs new behaviour:

UPDATE T SET A = B, B = A

old result: A gets equal to B, B doesn’t change

new result: A and B get their values exchanged

Change this configuration option to 1 (true) only if your SQL code relies on the legacy semantics of the SET clause. It’s provided as a temporary solution for backward compatibility issues and is removed in Firebird 3.0
Type: boolean

OldSetClauseSemantics = 0

Fixed in Firebird 2.5.2 and 3.0.x CHAR_TO_UUID and GEN_UUID works different in big/little endian architectures

Important CHAR_TO_UUID CORE bug fix for for big-endian servers (ex: debian on IBM s390x or sparc64/powerpc) also that fixes GEN_UUID to return a compliant RFC-4122 UUID:

It has been discovered that before Firebird 2.5.2, CHAR_TO_UUID and UUID_TO_CHAR works incorrectly in big-endian servers. In these machines, bytes/characters are swapped and goes in wrong positions when converting. This bug was fixed in 2.5.2 and 3.0, but that means these functions now returns different values (for the same input parameter) than before.

ps: And here is Firebird development discussion and here is the full patch

If you want to know on what endian os you have you can check the Endianness Table

1 102 103 104 105 106 294