Anti-Spam SMTP Proxy (ASSP) server supports Firebird
You can read more about it from Wikipedia and the announcement from it’s mailing list , and the thread that discussed about Firebird support.
You can read more about it from Wikipedia and the announcement from it’s mailing list , and the thread that discussed about Firebird support.
The Firebird JDBC team is happy to announce the release of Jaybird 2.2.0.
This release contains the following changes:
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(*):
The artifactId depends on your target Java version: jaybird-jdk15, jaybird-jdk16 or jaybird-jdk17.
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
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
Here is the bug with more info on how to help.
This bug needs to be fixed so we can replace Java-based HSQLDB database engine with Firebird in LibreOffice Base.
Accordingly to its release lifetime policy, Firebird Project notifies that the Firebird v2.0 series has reached its end of life and thus will not be maintained anymore. The last official release in this series, Firebird 2.0.7, which has been announced this year, will be available from the “discontinued” section of the download area.
The Firebird roadmap is updated , we are waiting for Firebird 3.0.x Alpha 🙂
I have had a few internal network penetration tests now in which I came across the following finding identified by McAfee Vulnerability Manager (MVM): “Firebird SQL Default Credentials Detected”. So I figured I’d share with you what is required to interact with the database and provide you with ideas on what you can do after you connect
After some hot discussion in Firebird-Java, I want to propose to ditch
the NONE as default character set for newly created databases when no
database charset is specified.
Read the rest of the full thread on Firebird-Devel.
I have posted a test version of FlameRobin: http://mghie.users.sourceforge.net/flamerobin_win32_test.zip
(a ZIP file containing only the 32 bit executables for Windows in ANSI and Unicode version) that uses a thread to establish the database connection. That
means that the progress dialog can be moved and cancelled, and the progress bar is updated in indeterminate mode. To see it in action it’s
best to try to connect to a database on a server which is not available or which doesn’t exist, which so far blocks FlameRobin completely until
the connection call times out. It would be great if people could test this and write (to flamerobin-devel) whether anything
breaks for them (it didn’t for me, yet). I’m a little of unsure if I should clean this up and commit…
Thanks
—
Michael Hieke
Highlights for this release:
Target for next release: Documentation