Modernizing the Firebird ODBC Driver: Moving to CMake and Cleaning House

As part of an ongoing effort to improve the project's infrastructure, we have just merged Pull Request #281, which introduces a modern CMake build system and drastically cleans up our repository by removing over 62,000 lines of obsolete configurations, old headers, and broken test projects.

This is the second phase of a three-part plan to streamline how the Firebird ODBC Driver is built and maintained.

What’s New: A Modern CMake Build System

Building the Firebird ODBC driver is now easier and more standardized. We've introduced a CMake build system that handles building the FirebirdODBC.dll driver, the IscDbc static library, and running our test suite via CTest.

One of the major improvements is that the build system now automatically downloads the Firebird 5.0.2 public headers from GitHub at build time, meaning we no longer have to manually vendor them in our repository.

For developers who prefer the existing Visual Studio 2022 solution, don't worry—it still works! You simply need to run a one-time CMake configuration step to fetch the headers before opening the solution as usual.

Spring Cleaning: Removing the Old

Over the years, the repository accumulated a lot of build configurations for platforms and compilers that have long been discontinued. In this update, we did some massive spring cleaning:

• Removed 14 Obsolete Build Configurations: We stripped out outdated build environments, including Borland C++ 5.5, Solaris, old macOS/Linux/FreeBSD makefiles, MinGW, and Visual Studio versions ranging from 6.0 (1998) up to 2008.
• Deleted Vendored Headers: We removed roughly 25,000 lines of vendored Firebird headers (FBClient.Headers) and system Windows SDK headers, relying instead on CMake to fetch them or the system SDK.
• Cleaned Up Tests: Old, non-functional test projects (like the JDBC-style test and legacy standalone apps) have been cleared out. They have been fully replaced by the Google Test suite introduced in our previous PR.

What Hasn't Changed?

While the infrastructure has seen a massive overhaul, the driver source code itself remains completely untouched. There are no changes to the source files, no new features, and no performance alterations.

We heavily validated the new CMake build against the old build system, confirming that the output FirebirdODBC.dll is perfectly binary-compatible and exposes the exact same 120 exported symbols as before.

---

Thanks to @fdcastel for authoring this massive infrastructure improvement!

New Google Test Suite Added to Firebird ODBC Driver

A major update has been merged into the FirebirdSQL/firebird-odbc-driver repository (PR #276), introducing a comprehensive Google Test suite to establish a strong regression testing baseline for the project. Authored by fdcastel, this addition is a crucial stepping stone before making future bug fixes or CI/CD improvements.

Key Highlights:

• Extensive Coverage: The PR adds a massive suite of 375 tests across 38 test suites, designed to exercise the Firebird ODBC driver directly through the standard ODBC API via the Driver Manager.
• Baseline Establishment: No driver source code was modified in this update. The goal is strictly to document what the current driver can do and precisely identify where improvements are needed.
• Pass vs. Skip Strategy: Out of the box, 230 tests pass, confirming that core features like data types, parameter binding, and catalog functions work correctly. The remaining 145 tests are skipped gracefully (GTEST_SKIP()), each serving as a documented placeholder for known gaps or missing features (like ODBC 3.8 compliance and specific crash fixes).
• Future-Proofing: This sets up a perfect "regression gate." As future patches and bug fixes are submitted, developers can simply remove the SKIP markers to activate the corresponding tests, proving that the fix works and preventing regressions.
• Standalone CMake Integration: The tests are housed in a self-contained CMake project that fetches Google Test, paving the way for easier integration into a future root CMake build.

This foundational work makes contributing to the Firebird ODBC Driver significantly safer and more measurable going forward!

Protocol Versions 16 and 17: Implement the latest protocol versions to support Firebird 4 features.

Implementing Firebird 4 Protocol Versions 16 and 17 is crucial for utilizing the advanced features, security enhancements, and performance improvements introduced in Firebird 4.0 and 4.0.1. Using updated clients that support these protocols prevents performance degradation and ensures access to modern functionalities.

Key Features Supported by Protocol 16 (Firebird 4.0)Wire Protocol Encryption: 

Enhances security by encrypting traffic between client and server.
Wire Protocol Compression: Reduces network traffic, boosting performance over high-latency connections.
Statement Timeouts: Allows setting maximum execution time for SQL statements.
Database Encryption Key Callback: Supports connecting to encrypted databases that act as their own security databases.
Packed (NULL-aware) Data: Optimized row data transmission.
Support for New Data Types: Specifically enables proper handling of INT128, DECFLOAT, and extended metadata length (up to 63 characters).

 

Key Features Supported by Protocol 17 (Firebird 4.0.1+) Batch Operations (API): Improved performance for high-volume data operations (Batch info request).
Sync Batch: Allows synchronization of batch information in the API.

Implementation and Compatibility ConsiderationsNegotiation: When a client connects, Firebird negotiates the protocol version. To use new features, the client library (e.g., fbclient.dll) must be version 4.0 or higher.

Performance Impact: Using older clients (e.g., v3.0) with a Firebird 4 server forces a lower protocol version, causing lost performance benefits and missing security features.

Driver Updates: It is essential to update drivers like Jaybird (Java), Firebird.NET, and other database connectors to their latest versions to support protocol 16/17.
Check Protocol in Use: You can check the active client version using SELECT DISTINCT MON$CLIENT_VERSION FROM MON$ATTACHMENTS.

Related protocol changes documentation