Announcing node-firebird v2.6.0: TypeScript 7, Query Cancellation, Firebird 6.0 Support, and More

We are thrilled to share the journey of our last 7 releases (from v2.3.3 to v2.6.0), which mark one of the most transformative periods in the history of the node-firebird driver.

With this series of releases, we’ve migrated the driver to native TypeScript 7, implemented native Promise & async/await APIs, added support for Firebird 5.0 and 6.0 features, and introduced robust query cancellation support.

Here is a comprehensive summary of what's new and why you should upgrade today!

---

🌟 Key Highlights & Milestones

1. The TypeScript 7 Era

In v2.4.0, we successfully converted the entire project to native TypeScript 7. This ensures type safety across the driver, provides a better developer experience, and guarantees native compilation without overhead.

2. Modern Promises & async/await API

Beginning in v2.5.0 (TypeScript Phase B), we introduced a modern Promise-based API alongside the classic callback structure. You can now write clean, modern asynchronous code using async/await naturally.

3. Query Cancellation via AbortSignal

With the release of v2.6.0, we’ve added full query cancellation support. By using standard JavaScript AbortSignal, you can cancel long-running queries via op_cancel protocol interactions.

4. Firebird 6.0 & 5.0 Feature Parity

node-firebird now fully supports modern database engines:

• Firebird 6.0 Support: SQL Schemas, Tablespaces, Native JSON, Named Arguments mapping, ROW types, and Protocol Version List Limit (maxNegotiatedProtocols).
• Firebird 5.0 Support: Scrollable Cursors, RETURNING Multi-Rows, SKIP LOCKED operations, Parallel Workers, and Inline BLOBs.

---

📅 Release-by-Release Breakdown

🚀 v2.6.0 — Query Cancellation

• Query Cancellation: Full implementation of op_cancel allowing you to pass an AbortSignal to cancel queries mid-flight.
• Release Page: v2.6.0 Release Notes

🚀 v2.5.0 — TypeScript Phase B & Safety

• Promises/async-await: Expanded TypeScript Phase B compiler improvements to support async/await structures.
• Security & Logging: SRP handshake logging is now gated strictly behind FIREBIRD_DEBUG, ensuring database credentials and secrets are never leaked in logs.
• Roadmap Updates: Added a comprehensive driver-parity comparison against popular database drivers (like pg and mysql2).
• Release Page: v2.5.0 Release Notes

🚀 v2.4.2 — Documentation Refresher

• Developer Resources: Added a complete table of contents, community/resources index, and a comprehensive contributing guide to encourage community participation.
• Release Page: v2.4.2 Release Notes

🚀 v2.4.1 — Clean Up & Refinement

• Modern Tooling: Refreshed README and ROADMAP for the TypeScript 7 era and tidied up the repository root.
• Release Page: v2.4.1 Release Notes

🚀 v2.4.0 — The Big Upgrade: TypeScript 7 & Firebird 6.0

Our largest release in recent history, packing major feature upgrades:

• TypeScript 7 Migration: Moved the compiler and codebases to native TS7.
• Firebird 6.0 Features: Added SQL Schemas, Tablespaces, Native JSON, ROW type, named argument mappings, and protocol negotiating limits.
• Firebird 5.0 Features: Scrollable Cursors, inline BLOBs, SKIP LOCKED support, and RETURNING clause enhancements.
• Authentication & Wire Encryption: Dynamic srp256/384/512 authentication and modern chacha/chacha64 wire encryption support.
• Stability Fixes: Corrected in-flight event notification duplications, fixed preparation hangs on Firebird 6.0, and prevented callbacks from hanging when a connection is abruptly lost mid-flight.
• Release Page: v2.4.0 Release Notes

🚀 v2.3.4 — Dependency Maintenance

• Lockfile Updates: Routine maintenance and package lock updates to ensure clean and secure builds.
• Release Page: v2.3.4 Release Notes

🚀 v2.3.3 — Protocol Adjustments & Stability

• Connection & Encoding: Connection-level character set mapping fixes, TCP keep-alive settings, and a new connectTimeout parameter.
• BLOB Enhancements: Implemented blobReadChunkSize and serialized blob reading internally to prevent deadlocks under Firebird's concurrent handle limits.
• Platform Support: Added a proxy trap to bind socket methods for seamless compatibility with Deno.
• Release Page: v2.3.3 Release Notes

---

🛠️ Upgrading

Getting the latest improvements is as simple as upgrading via npm:

npm install node-firebird@latest

We want to thank all our contributors and the community for their feedback, bug reports, and pull requests that helped make this modern era of node-firebird possible!

Have questions or want to help contribute? Head over to the GitHub Repository and join the discussion.

Working on new Firebird VS code extension , still work in progress

Not bad for a few days of work , There are still lot's of bugs and UI inconsistencies 

ps: It's a fork of existing extension but using updated node drivers and updated roadmap (Firebird 6 support / Typescript 6.x)

pps: I need to recover my MFA Azure Developer account to publish it soon 

Going Native-Free: Introducing the Pure Node.js Wire Driver for Firebird

Published in Engineering • Pull Request #168 Summary

If you have ever built Node.js applications that communicate with a Firebird database, you are likely familiar with the standard setup routine. Traditionally, high-level drivers depended heavily on the native client library (fbclient).

While highly optimized, relying on a native dynamic link library (.dll, .so, or .dylib) frequently meant dealing with tedious cross-platform installation headaches, complex environment paths, and architecture mismatches.

That era is coming to a close. With the merging of Pull Request #168, the node-firebird-drivers ecosystem is taking a massive leap forward by introducing a completely native-free, pure TypeScript/JavaScript implementation: node-firebird-driver-wire.

The Problem: The Heavy Weight of Native Clients

Up until now, configuring Firebird in a modern Node.js environment usually required pointing your package to a local installation of the Firebird client. If you deployed your application inside a streamlined Docker container or onto a serverless environment (like AWS Lambda), getting those native client binaries to coordinate correctly could be a major chore.

The Solution: PR #168 and node-firebird-driver-wire

PR #168 fulfills a highly anticipated community request (tracked under Issue #166) to introduce a pure Node.js wire protocol driver.

Instead of wrapping around C++ bindings or hooking into a local fbclient library, this driver implements Firebird's native network protocol completely from scratch using standard Node.js TCP sockets (net.Socket).

What this means for developers:

• Zero Native Dependencies: You no longer need to ensure that fbclient is installed on your host system.
• Seamless Cross-Platform Portability: Written in pure JS/TS, the code runs identically on Windows, Linux, and macOS without local compilation.
• Streamlined Container Deployment: Building lightweight Docker containers (like Node-Alpine) is straightforward without OS-level database packages.

Architectural Overview

Under the hood, PR #168 establishes a modular separation within the monorepo:

1. node-firebird-driver: The shared interface layer containing universal definitions.
2. node-firebird-driver-native: The legacy client layer that directly talks to the native C++ API.
3. node-firebird-driver-wire (New!): The pure JS/TS layer that encodes and decodes the wire protocol over raw network sockets.

How to Use It

Switching to the wire driver mirrors the syntax of its native counterpart:

import { createWireClient } from 'node-firebird-driver-wire';

async function main() {
    const client = createWireClient();
    
    const attachment = await client.connect('localhost:3050/your-database.fdb', {
        username: 'SYSDBA',
        password: 'masterkey'
    });

    const transaction = await attachment.startTransaction();
    const resultSet = await attachment.execute(transaction, 'SELECT * FROM USERS');
    
    // ... process database logic ...

    await transaction.commit();
    await attachment.disconnect();
}

---

Wrapping Up

PR #168 marks a significant milestone for the Node.js and Firebird developer communities. By shedding the requirement for native underlying libraries, node-firebird-driver-wire positions Firebird as a modern, nimble, and serverless-friendly option for JavaScript developers.

Practical Firebird Performance Diagnostics: A Structured Approach

IBPhoenix is pleased to announce the release of a new free ebook:

Practical Firebird Performance Diagnostics: A Structured Approach

Unlike traditional performance tuning guides, this ebook focuses on the reasoning behind successful diagnostics. It introduces a structured framework that helps Firebird professionals move from observed symptoms to defensible explanations by classifying problems, selecting appropriate investigation strategies, interpreting evidence correctly, and using diagnostic tools with purpose.

The book covers the complete diagnostic process, from understanding why investigations fail to interpreting monitoring tables, trace sessions, profiler output, gstat reports, operating system metrics, and modern hardware behavior in the context of Firebird performance.

Whether you’re a database administrator, developer, consultant, or support engineer, this ebook provides a practical methodology for approaching complex performance problems with greater confidence and consistency.

The book is available for free from IBPhoenix store.

Happy reading!

Firebird Adds Unix Domain Socket Support

Firebird is gaining support for Unix Domain Sockets (UDS) through PR #9034, a feature aimed at improving local inter-process connectivity, especially in constrained environments like Android and iOS. The change introduces a new unix:// connection string format and a RemoteServiceUnixSocket configuration option, allowing Firebird clients and services to communicate over filesystem-based sockets instead of TCP.

This is a meaningful enhancement for mobile and sandboxed platforms, where filesystem permissions can be easier to manage than network ports. It also opens the door for scenarios where applications can launch a Firebird server process and connect to it locally even when embedded mode is not viable, which was the core motivation described in linked issue #9033.

From an implementation standpoint, the PR updates both client and server networking layers to recognize and handle AF_UNIX sockets, adds cleanup and auxiliary event-socket handling, and extends support to Windows environments that expose Unix socket APIs. It also updates configuration, build detection, and documentation so the new transport is visible and usable across supported platforms.

At a glance 

• PR: #9034 — Feature #9033 - Support for Unix Domain Sockets
• Author: asfernandes
• Status: Open, non-draft, mergeable
• Scope: 13 files changed, +544 / -27
• Commits: 2
• Linked feature request: #9033
• CI: Check runs completed on a broad platform matrix, including Linux, macOS, Windows, Docker, and Android builds

Why it matters

• Better fit for mobile and sandboxed environments
• Enables secure local connections based on filesystem permissions
• Reduces dependence on TCP for local-only communication
• Expands Firebird deployment flexibility for modern app runtimes

How Firebird’s New Parallel Sort Changes Everything

 

Breaking the Single-Thread Barrier: How Firebird’s New Parallel Sort Changes Everything

1. Introduction: The Multi-Core Paradox

There is a specific economic and technical frustration well-known to database architects: authorizing the purchase of high-end silicon with 64 or 128 cores, only to watch the OS scheduler show a single thread redlining while the rest of the hardware sits idle. Despite the massive processing power available, the internal logic of many database engines remains tethered to a sequential execution model. In this scenario, your return on investment for modern hardware is effectively throttled by legacy code, turning expensive multi-core chips into underutilized silicon.

Firebird SQL, with its architectural roots in the InterBase 6.0 legacy, has long been celebrated for its modularity and transactional robustness. However, it too faced the "serial bottleneck" where individual requests were confined to a single thread. Pull Request 8990 represents a paradigm shift for the engine. By moving from sequential processing to internal parallelism within the Journaling and Recovery Database (JRD) layer, Firebird is fundamentally evolving to meet the demands of modern hardware. This post explores the five most impactful technical breakthroughs from this architectural advancement.

2. Takeaway 1: Moving Beyond the "One Request, One Thread" Legacy

Firebird’s server models—Classic, SuperClassic, and SuperServer—were designed for an era where memory was the primary constraint and single-core performance was king. While SuperServer introduced multi-threading to manage concurrent connections, the execution of any single SQL statement remained strictly sequential. Even with dozens of cores available, a large sort operation was a monolithic task that could only utilize one.

PR 8990 is not a simple patch; it is a fundamental rethinking of the JRD layer. Specifically, it involves the transition of the JRD Task Manager from a simple serial queue to a robust central dispatcher. This new dispatcher model allows the engine to decompose complex operations into parallelizable segments that can be distributed across a global thread pool. By rethinking the core task-handling logic, Firebird can now treat a single query as a coordinated multi-threaded effort.

"As the database industry transitions from a focus on raw clock speed to the exploitation of massive core counts, the internal mechanisms of relational engines must evolve to avoid becoming performance bottlenecks."

3. Takeaway 2: The "Snapshot" Secret to Parallel ACID Compliance

Maintaining Multi-Version Concurrency Control (MVCC) while multiple threads sort data simultaneously is a significant technical hurdle. Every record version’s visibility must be checked against the Transaction Inventory Page (TIP), which tracks whether transactions are active, committed, or rolled back. In a standard sequential execution, this check is a linear process; in a parallel environment, it risks becoming a nightmare of disk contention and locking.

To solve this, PR 8990 utilizes a snapshot-based approach to the TIP. Before a parallel sort begins, the primary thread captures an immutable list of transaction states. This snapshot is shared with all worker threads. Because this view of the database state is "frozen" for the duration of the sort, worker threads can perform visibility checks independently. This is a brilliant architectural trade-off: by creating an immutable local copy of transaction states, the engine eliminates the need for workers to lock or even access the actual TIP pages on disk, significantly increasing concurrency and throughput.

4. Takeaway 3: A Mathematical Facelift for Big Data

The transition to parallel sorting fundamentally alters the mathematical complexity of query execution. The engine now employs a parallel external merge sort that utilizes a "cascading merge" strategy. This is specifically designed to address Amdahl’s Law by minimizing the "serial fraction"—the part of the code that cannot be parallelized. By allowing worker threads to merge groups of runs (e.g., four threads each merging 25 runs into intermediate blocks), the engine prevents the primary thread from becoming a bottleneck during the final merge phase.

Operation Phase	Sequential Complexity	Parallel Complexity (PR 8990)
Data Fetching	O(n)	O(n/p) (I/O dependent)
In-Memory Sort	O(n \log n)	O((n/p) \log (n/p))
Disk I/O (Runs)	O(n)	O(n) (Often I/O bound)
Merging Phase	O(n \log k)	O((n/p) \log k)

Key: n = number of records, p = number of parallel workers, k = number of runs being merged.

By partitioning the data stream and allowing worker threads to handle blocks and merges simultaneously, the engine achieves high efficiency even on systems with 32 or 64 cores.

5. Takeaway 4: The Hidden Performance Multiplier for Indexing

While the benefits to ORDER BY and GROUP BY are the most visible, the secondary impact on metadata maintenance is a game-changer. A CREATE INDEX statement is essentially a massive sort operation followed by B-tree construction. On tables with billions of rows, these operations traditionally took hours, creating massive maintenance windows.

PR 8990 applies the parallel sort framework to indexing, reducing these windows to a fraction of their former time. Furthermore, the architecture prioritizes a "Safety First" design. The SortManager is engineered to handle exceptions with surgical precision: if a worker thread fails due to a disk error or resource constraint, the SortManager catches the exception, terminates the remaining workers, and cleans up temporary files. This ensures that even under failure conditions, the database remains in a consistent state without orphaned temporary data.

6. Takeaway 5: Surgical Precision in Resource Management

Administrators gain granular control over this new power through updates to firebird.conf and databases.conf. This is facilitated by Firebird's support for scoped-value configuration, allowing different performance profiles for different databases on the same instance.

Key parameters include MaxParallelWorkers and ParallelWorkerStackSize. Tuning the stack size is particularly crucial; it allows architects to prevent memory exhaustion when high worker counts are required. To minimize overhead, the engine utilizes a "warm thread pool"—threads stay alive and wait for signals from the JRD Task Manager, avoiding the expensive lifecycle costs of creating and destroying threads for every task.

# databases.conf example: Scoped-value support
# High-parallelism for analytical workloads
AnalyticalDB = /databases/analytics.fdb { 
    MaxParallelWorkers = 16 
    ParallelWorkerStackSize = 512K
    TempCacheLimit = 2G 
}

# Restricted parallelism for high-concurrency OLTP
OLTP_DB = /databases/transactions.fdb { 
    MaxParallelWorkers = 2 
}

Importantly, these operations are fully observable. Administrators can monitor parallel utilization in real-time via the MON$STATEMENTS table using the new MON$PARALLEL_WORKERS column, providing the transparency needed to fine-tune production environments.

7. Conclusion: The Future is Parallel

Pull Request 8990 is more than an optimization; it is a foundational milestone. The task manager and worker thread framework established here serve as the infrastructure for future parallel advancements, such as parallel table scans, join algorithms, and background garbage collection.

As datasets grow toward terabyte scales, the criteria for selecting a database engine must change. In an era where 64-core processors are the standard entry point for servers, a database that cannot parallelize its internal tasks is no longer a tool; it’s a liability. With this shift, Firebird demonstrates its ability to maximize local resource utilization and secures its trajectory as a high-performance, open-source RDBMS ready for the most demanding modern workloads.

Help Us Test the New Firebird Docker Images

Major Update: Help Us Test the New Firebird Docker Images

We have been working on a significant overhaul of the official firebird-docker images, and a pre-release version is now available for testing at:

Pre-release Container Registry

We would love to get feedback from the community before these changes are merged upstream.

---

What’s New

Firebird 6 Snapshot Images

The new images include a 6-snapshot tag built daily from the master branch of FirebirdSQL/firebird. This is the first time a Firebird 6 development snapshot has been available as a Docker image.

# Pull the latest Firebird 6 development snapshot
docker pull ghcr.io/fdcastel/firebird:6-snapshot

# Pull the latest Firebird 5 patch snapshot
docker pull ghcr.io/fdcastel/firebird:5-snapshot

Snapshot images are rebuilt daily, so you always get the latest development build.

Expanded Version Coverage

The image matrix has been significantly expanded to cover more versions and distributions:

• Firebird 3.x: 3.0.8 through 3.0.13 (amd64 only; bookworm, bullseye, jammy)
• Firebird 4.x: 4.0.0 through 4.0.6 (amd64; bookworm, bullseye, jammy, noble)
• Firebird 5.x: 5.0.0 through 5.0.3 (amd64 + arm64; bookworm, bullseye, jammy, noble)
• Firebird 6 snapshot: Daily build from master (amd64 + arm64)
• Firebird 5 snapshot: Daily build from v5.0-release (amd64 + arm64)

---

How to Test

Pull the images directly from our pre-release registry to see how they perform in your environment:

# Latest stable (Firebird 5.0.3 on bookworm)
docker pull ghcr.io/fdcastel/firebird:latest

# Firebird 6 development snapshot ← Most wanted testers here!
docker pull ghcr.io/fdcastel/firebird:6-snapshot

# A specific version + distro
docker pull ghcr.io/fdcastel/firebird:5.0.3-jammy
docker pull ghcr.io/fdcastel/firebird:4.0.6-bookworm

We are especially looking for feedback on:

• Starting a container and connecting via isql or your preferred driver.
• ARM64 performance if you have compatible hardware (M-series Macs, Ampere, etc.).
• Firebird 6 snapshot behavior: Any connection issues, startup errors, or unexpected behavior changes.

⚠️ Important: Pre-Release Notice

These images have not yet been merged into the official repository and may contain bugs. The Firebird 6 snapshot, in particular, is built from unreleased, in-development code.

Warning: Do not use pre-release or snapshot images in production environments. Snapshot tags (6-snapshot, 5-snapshot) are rebuilt daily and do not carry stability guarantees.

---

Feedback

Your input is vital to making these images solid before the official merge. Please report any issues, successful test results, or suggestions at the upstream pull request:

🔗 GitHub Pull Request #36

Whether it’s a simple "works great on my ARM64 machine" or a detailed bug report, all feedback is welcome.

Thank you for helping us improve the Firebird ecosystem!

— F.D. Castel

FlameRobin 0.9.16 released

FlameRobin 0.9.16 released focuses on: modernizing CI/build tooling fixing compiler/linker issues , improving packaging (Flatpak), and delivering a set of Firebird metadata/DDL extraction and SQL editor correctness improvements

https://github.com/mariuz/flamerobin/releases/tag/0.9.16

PSFirebird: PowerShell Automation for Firebird on Windows and Linux

PSFirebird is a PowerShell module focused on automating Firebird environments, databases, and common administrative workflows. The main goal is to make Firebird easier to script end-to-end without depending on a manual installer flow or a machine-specific setup.

The problem is trying to solve was simple: working with Firebird in automation often means mixing shell scripts, ad hoc local installs, version-specific quirks, and CI setup glue. That gets especially painful when you need to test multiple Firebird versions, rehearse upgrades, or spin up disposable databases for integration tests. PSFirebird is designed to reduce that friction.

What PSFirebird Does

Today the module can:

• Download official Firebird release assets and prepare portable environments
• Run multiple Firebird versions side by side
• Create, inspect, read, test, and remove databases
• Execute SQL through isql from PowerShell
• Read and update firebird.conf
• Start ad hoc Firebird instances
• Register Firebird as a Windows service or Linux systemd service
• Backup and restore databases
• Convert databases across Firebird versions with streaming backup/restore
• Lock and unlock databases for filesystem-level copy using nbackup
• Parse gstat output into structured PowerShell objects for tables and indices

The current codebase targets PowerShell 7.4+ on Windows and Linux. On Linux, the environment bootstrap currently targets Debian-based systems.

Why I Think This is Useful

PSFirebird is not meant to be another GUI admin tool. It is aimed at repeatable automation.

Some scenarios where it should be useful:

• CI/CD pipelines that need a Firebird server on demand
• Test matrices that need Firebird 3.x, 4.x, and 5.x side by side
• Upgrade rehearsals from older databases to newer engine versions
• Disposable local environments for development and debugging
• Scripting routine admin tasks instead of doing everything manually

One of the most useful parts for me is the ability to create isolated Firebird environments directly from PowerShell, then run the rest of the workflow against that environment in a predictable way.

This project builds on earlier work I’ve done across several Firebird community initiatives such as SqlAlchemy-Firebird, the Firebird .NET Provider, the Firebird ODBC Driver, and the Python driver. Across all of these efforts, maintaining a robust and consistently repeatable testing foundation has been essential.

Example

Here is a small example that prepares two Firebird versions and converts a database from one environment to another:

$tempPath = [System.IO.Path]::GetTempPath()
$fb3 = New-FirebirdEnvironment -Version '3.0.12' -Path (Join-Path $tempPath 'fb3')
$fb5 = New-FirebirdEnvironment -Version '5.0.3' -Path (Join-Path $tempPath 'fb5')
$sourcePath = Join-Path $tempPath 'legacy.fdb'
$targetPath = Join-Path $tempPath 'legacy.fb50.fdb'

$db = New-FirebirdDatabase -Database $sourcePath -Environment $fb3 -Force

$env:ISC_USER = 'SYSDBA'
$env:ISC_PASSWORD = 'masterkey'
Convert-FirebirdDatabase -SourceDatabase $db -SourceEnvironment $fb3 -TargetDatabase $targetPath -TargetEnvironment $fb5 -Force

The module also includes helpers for scoped environment usage, configuration editing, SQL execution, service management, and database statistics collection.

Project Status

This is a real automation-oriented codebase, not just a thin proof of concept. The repository already includes:

• Unit tests
• Integration tests
• Cross-version conversion tests
• Windows and Linux CI coverage
• A GitHub Actions example showing end-to-end module usage in a workflow

Feedback Wanted

If you work with Firebird, I would especially like feedback on:

• Missing administrative workflows
• Cross-platform behavior and Linux packaging assumptions
• Upgrade and migration scenarios
• Command naming and module ergonomics
• CI and testing use cases

GitHub repository: https://github.com/fdcastel/PSFirebird

If this looks useful for your environment, take a look and let us know what would make it more practical for real-world Firebird automation.

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