Firebird News

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.

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!

With Firebird’s 25th anniversary behind us, this edition looks forward, focusing on the challenges of understanding and operating long-lived database systems. It explores how performance and behavior often emerge from interactions across the system, rather than from isolated components, and examines how database vulnerabilities are assessed and interpreted in practice.

As always, the issue is presented in a clean, print-friendly layout designed for enjoyable reading, whether on screen or on paper.

The latest issue is available only to all Firebird Associates and Firebird Partners. It will be available to the general public in June 2026.

Also, the December 2025 issue is now available to all readers.

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, 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!

Jiří Činčura announced the release of Entity Framework Core 10 provider for Firebird.

Shout out to @niekschoemaker who did most of the work.

Overview of all the changes can be found in here and you can get the bits from NuGet FirebirdSql.EntityFrameworkCore.Firebird.