Search results for "contact"

Our replication extension for Firebird 2.5–5.0 turns your database platform into a robust, flexibly scalable system – without the typical limitations of classic standard replication mechanisms. Whether you need high availability, a reporting database, geographical distribution or load balancing, you remain in control – even during live operation.

The solution can be integrated into existing third-party software that works with Firebird 2.5 - 5.0 and can also be marketed by software manufacturers as an enterprise feature to complement their own applications.

Advantages at a glance

1) Switch replication on and off at any time – with no downtime

Activate or deactivate replication during ongoing operation without having to stop the master database. This means that maintenance, testing, conversions or temporary shutdowns are possible without interrupting your productive processes.

2) Error-tolerant and fail-safe – continue working without any data loss

If the server running the replicated database fails, your system will continue to operate without any data loss. As soon as the target server is available again, the extension automatically restores replication and reliably synchronizes any changes that have been made in the meantime.

3) Scalable: One-to-many with no architectural changes

One master, multiple targets: Use the solution without any changes as 1:n replication (one master replicates to multiple targets) – ideal for reporting, read scaling, branch/location solutions or separate systems for analysis and operation.

4) Multi-master perspective – near-time synchronous or asynchronous

With targeted adjustments to your software – particularly when assigning primary keys – the solution can also be operated as synchronous or asynchronous near-time multi-master replication: writing is possible on every server, and all others then receive the changes. This allows you to lay the foundation for genuine distributed write scenarios and maximum availability.

IBExpert company workshops – implementation, source code and expertise included

IBExpert offers company workshops for precisely this solution, in which not only the basics are taught, but replication is also implemented specifically on your customer database – including clear documentation and operational setup.

What will be implemented and documented in the workshop

In the workshop, implementation will be individually tailored to your specific environment. This includes, among other things:

      Integration of the solution with your customer database (Firebird 2.5 - 5.0)
      Documentation of the customer-specific setup (operating and restart concept)
      Provision of ready-to-use batch files, e.g. for:
            Initialisation (initial synchronisation/initial setup of replication)
            Starting the replication
            Stopping replication
            Backup/restore of the replicate (including restart after restore)
Optional: Standardised processes for replicate refresh and recovery

Remote training (up to 6 hours) included

Each workshop includes up to 6 hours of remote training, during which the system is activated on your actual customer database. The necessary expertise for subsequent operation (monitoring, troubleshooting, restart scenarios, update/maintenance procedures) is developed jointly during this training.

Important prerequisite (and alternative should it not be met)

Ideally, all tables which are to be replicated should have a primary key.

If this is not possible for certain reasons, we can also replicate such databases – including with Firebird 2.5 – 5.0, albeit using alternative technology developed in-house. 

Source code & usage rights for workshop participants (user companies)

        Workshop participants receive the complete source code.
        The source code is provided in a form that is executable for Firebird 2.5 - 5.0.
        The company may use the solution on its own computers/systems without any restrictions.

Source code & usage rights for software manufacturers/ISVs (marketing as an enterprise feature)

        Software manufacturers may use the solution on up to 10 customer installations at no extra charge.
        For more than 10 customer installations, an OEM price for resale can be obtained on request.
        The result: greater availability, greater control, greater scope for growth.

Instead of treating replication as a rigid ‘on/off’ construct, you get a system that adapts to your operational reality: maintenance-friendly, fail-safe, scalable – and ready for sophisticated setups, right up to multi-master concepts.

Cost: EUR 4,999 (net of sales tax)

Contact us with absolutely no obligation! Contact our team at register@ibexpert.net or start a personal Signal chat directly:

IBExpert 2026.10.12

(and bugfix 2026.11.03)

1. "Goto column" feature in data grids

Available from the context menu, default shortcut is [Ctrl] + [Shift] + [G].

This feature shows a list of visible columns of a dataset with the possibility to filter them and focus a selected column.

It displays a small pop-up with an alphabetical, searchable list of all column headers. Select a column and the grid is focussed on that specific column without moving it or modifying the SQL query.

2. Highlighting of system tables in the windows bar. "System objects color" is used for highlighting.

3. Table selector 

- combobox on the toolbar with list of database tables - in the Table Editor it was replaced with bar button. Using that button you can choose another table for editing via improved "Select object" dialog wich supports schemas and filtering.

This is only for existing tables; there is still a combobox there for a new Table Editor.

This combobox will be replaced in all other editors that have it in future IBExpert versions.

4. Database Comparer

There are a lot of changes in the Database comparer to facilitate use with Firebird 6.

IBExpert 2026.07.26

(and bugfixes 2026.08.20)

This version includes further adaptations and optimisations to new Firebird 6 features, along with minor bugfixes and improvements.

IBExpert 2026.02.22

(and bugfixes 2026.03.01/2026.03.04/2026.03.15/2026.13.19/2026.03.31/2026.04.02/2026.05.22/2026.05.26/2026.05.28/2026.06.02)

The main improvement in this version is support for schemas in the Extract Metadata engine and everything around it: the Extract metadata feature itself, the ibec_ExtractMetadata function and other places where pFIBExtract is used. 

IBExpert 2025.08.04

(and bugfixes 2025.08.08/2025.10.29/2025.10.31/2025.11.07/2025.11.12/
2025.11.17/2025.12.19/2025.12.23)

1. SQL Editor

• Support for CALL statement (FB 6).
• Support for SHOW (WIRE_STATISTICS | WIRE_STATS) command (FB 6).
  The command show values of wire statistics counters, accumulated since the connection start time.

2. Database Inside

• Initial support for FB 6 databases.

3. New trace session form

• "Initial view mode" option implemented.

4. Other minor bugfixes and improvements

IBExpert 2025.06.09

(and bugfixes 2025.06.18/2025.06.24)

1. Initial support for Firebird 6 implemented

2. Blob editor

• Improvement: Two or more blob editors can now be opened at the same time.
  To start a second, third etc. blob editor use the "New blob editor" button in an already opened blob editor.

3. SQL Editor

• Improvement (Firebird 6): EXPLAIN <query> 
  - Prepares <query> and gets its plan in the usual way.
  - Executes "select * from rdb$sql.explain(<query>)" and shows results in the data grid.

4. DB Explorer

• Bugfix: Missing colorization of incremental search results if the database connection charset is UTF8.

5. IBEBlock

• Bugfix: ibec_CompareMetadata ignored stored functions and packages if Firebird 4.0 or Firebird 5.0 is specified as the server version. 
• Improvement: FOR loop now supports DOWNTO and BY clauses similar to Firebird 6 syntax.

6. Minor bugfixes and small improvements

IBExpert 2024.12.01

(and bugfixes 2024.12.04/2025.02.05/2025.02.27/2025.03.07/2025.03.28/2025.04.22/2025.05.08)

1. Event blocks

• "Before start trace session" event block implemented.
  See \Blocks\Templates\EventBlocks\TAS.BeforeStartTraceSession.ibeblock for an example.
  Also see description of new "Quick start trace session" feature below.

2. Code editors

• Support for multilevels in User actions submenu.
  See \Blocks\Templates\EventBlocks\CodeEditorUserActions.ibeblock for a working example.

3. Database Comparer

• Fixed the problem with missing stored functions and packages while comparing Firebird 5 databases.

4. Quick start trace session feature implemented

• This feature is intended to start a trace session for an active connection with a single click.
• Default trace config is provided by IBExpert and can be modified in the "Before start trace session" event block which is fired when quick start or regular start (Services | Trace and Audit | Start new trace session) is performed.
  
  There are several other properties of trace session and trace form which can be customized in the "Before start trace session" event block.
  
  See \Blocks\Templates\EventBlocks\TAS.BeforeStartTraceSession.ibeblock for complete example.

• To quick start a trace session, use the corresponding button on the main form tool button. Alternatively it can be done using the [Ctrl] + [Shift] + [T] shortcut.

5. IBEBlock

• ibec_psql_PreprocessPSQL function implemented.
  
  It inserts some placeholders in the form of single line comments into a provided PSQL source (procedures, functions, triggers and package routines) which can be later replaced with additional debug statements (INSERT into a log table etc.). For a complete example see \Blocks\DefaultBlocks\PSQL.PrepareForDebug.ibeblock.
  
  There is also a working implementation of calling this block from \Blocks\Templates\EventBlocks\ CodeEditorUserActions.ibeblock which performs the preparation of the PSQL source for debugging and removes debug statements and comments from the PSQL source when they are no longer needed.

• @SysUtils.GetFilePath function implemented.
  
  The function sequentially checks the specified folders for the presence of the file. If the folder contains the specified file, the function returns the full path to it and exits. Otherwise, it returns NULL.

Example:

    ...

    sBlockFileName = 'PSQL.PrepareForDebug.ibeblock';
    sBlockFilePath = @SysUtils.GetFilePath(sBlockFileName,
       ibec_GetEnvironmentVariable('IBE_USERBLOCKSDIR'),
       ibec_Coalesce(ibec_GetEnvironmentVariable('IBE_APPDIR'), '') + '\Blocks\DefaultBlocks');

    if (sBlockFilePath is null) then
    begin
      ibec_ShowMessage('Looks like ''' + sBlockFileName + '''is missing...');
      Exit;
    end; 

6. Minor bugfixes and small improvements

IBExpert 2024.04.07

1. Database Registration

"Show server version mismatch warning" option added (Additional tab). 

If this option is ON (default) IBExpert will compare the specified and the actual version of the database and warn in case of a mismatch with a choice of possible actions.

2. PSQL Debugger

Support for time zones implemented (Firebird 4, 5). 

3. Data Grids

The possibility to dump blobs to file without preloading them into the IBExpert GUI has been implemented; it is available from the grid context menu.

Fixed the issue with incorrect representation of RDB$DB_KEY for tables with >2G records. 

4. Code Completion

Fixed the incorrect behaviour when selecting/unselecting items in the list using the mouse. 

5. Database Inside

Support for Firebird 5 databases. 

6. SQL Editor, Statements History List

Added counters for page operations. 

7. Database Comparer

Support for parenthesized SELECTs (Firebird 5) implemented. 

8. Other minor bugfixes and small improvements

IBExpert 2024.01.22

Mainly bug fixes.

IBExpert 2023.11.22

Mainly bug fixes.

IBExpert 2023.10.27

1. Code Editor, Code Completion

• Improved performance especially on databases with lot of objects.
• Suggesting possible joins based on existing relationships by foreign keys - call the Code Completion after JOIN keyword.
• There was a bug on some configurations in the previous version which caused IBExpert to freeze when the Code Completion is fires. Fixed in this version.

2. Database Inside

• Support for Firebird 4 databases.

3. Partial support for Firebird 5 implemented

• Support for all known syntax changes/additions in the PSQL parser:

     SKIP LOCKED, WHEN NOT MATCHED BY SOURCE, parenthesized SELECTs etc.

     However, there is NO support yet for parenthesized SELECTs in the Database Comparer.
     Also the PSQL debugger doesn't allow to debug roitines with subroutines which reference variables in a main routine.

• Support for new built-in functions in the Code Parameters hint.
• Support for partial indices in the index editors and metadata extract.
• Support for parallel workers in following IBEBlock functions:

    ibec_BackupDatabase, ibec_RestoreDatabase, @Services.RepairDatabase.

      There is a new option available - ParallelWorkers (or just Parallel) - which allows to specify number of parallel workers (e.g. ParallelWorkers=4)

4. Other minor bugfixes and small improvements

IBExpert 2023.09.13

Mainly bug fixes.

IBExpert 2023.07.09

1. DB Explorer

•   Activating/deactivating database objects from the Project View tree.

2. Search in Metadata

•   Possibility to search in scripts/blocks (IBE$SCRIPTS table) has been implemented.

3. Code Editors

•  Hyperlinks behaviour for package routines implemented.
• "Before load from file" event block implemented. This block allows you to perform some actions before the appearance of the "Open file" dialog; for example, change a source directory. See block template for more details.
• "Init/perform user actions" event block implemented. This block allows you to define user actions with code editor content which will be executed via a shortcut and/or from the code editor context menu (the very first item in the menu, if the block exists and is active). See block template for more details.

4. Dependencies trees

•   Solved some issues with the incorrect display of package dependencies.

5. Copy Database Object

• Support of SQL role in copy blocks added.

6. IBEBlock

• @Services.RepairDatabase and @Services.SetDBProperties functions implemented. 

    Example:

    execute ibeblock

    as
    begin
      -- Both functions return nothing (NULL) if there were no errors, 
      -- otherwise they will return an error message 

      sDBName = 'dbserver/3053:D:\databases\db.fdb';
      sConnectParams = 'ClientLib="D:\ClientLibs\fbclient_30.dll"; User=SYSDBA; Password=masterkey;';

      -- Supported repair params: Limbo, CheckDB, IgnoreChecksum, 
      -- KillShadows, Mend, Sweep, Validate, ValidateFull

      Res = @Services.RepairDatabase(:sDBName, :sConnectParams || 'Mend');

      if (Res is not null) then
        ibec_ShowMessage(Res); 

      -- All supported params are listed in the example

      Res = @Services.SetDBProperties(:sDBName, :sConnectParams || 'PageBuffers=2048; SQLDialect=3;
            SweepInterval=20000; ForcedWrites=TRUE; ReadOnly=FALSE');

      if (Res is not null) then
        ibec_ShowMessage(Res);

    end;

• ibec_ExtractMetadata function:
  ExtractPrimaryKeys and ExtractUniques options added to prevent extraction of primary keys and unique constraints. Together with the existing ExtractReferences and ExtractChecks these options allow you to suppress the extraction of all constraints.
  
  By default all of these options are ON (TRUE). To disable the extraction of primary keys, for example, set the corresponding option to FALSE: ExtractPrimaryKeys=FALSE.
  
  
• Code Editor namespace with set of functions implemented. See example of usage in the "Init/perform user actions" event block template.

7. Minor bugfixes and small improvements

IBExpert 2023.04.14

Minor bugfixes and small improvements.

IBExpert 2023.03.06

 1. Data Grid

• Possibility to edit UUID/OCTETS values in the filter criteria tree has been implemented.
• The mouse wheel can now be used to perform Page Up and Page Down actions.
• By default the Ctrl key should be held to perform PageUp/PageDown.
• To change the default modifier put the following piece of code into the After IBExpert starts event block:

    ibec_SetGlobalVar('IBE$DATA_GRID_PAGE_SCROLL_MODIFIER', <value>);

        where <value> is one of following: empty string, null, 'CTRL', 'ALT', 'SHIFT'.

        An empty string or null as a new modifier value makes PageDown/PageUp a default                behaviour of the mouse wheel in the Data Grid.

2. Code Editor

• Support of keyboard templates in the Code Completion list.
  There is a new option Show keyboard templates in Code Completion list in the Options | Editor Options | Code Insight.

3. Automatic restore of a dead connection

• By default if the database connection is lost IBExpert shows a dialog window and offers to restore a dead connection. To attempt to restore the connection automatically without user confirmation put following line of code into the After IBExpert starts event block:

    ibec_SetGlobalVar('IBE$RESTORE_DEAD_CONNECTION', TRUE);

4. Database Object Editors

• Support of object names longer than 31 chars (Firebird 4) where they were not yet supported.

5. Export Data

• Export to clipboard in JSON format implemented.

6. Code Formatter

• Support of space after opening and before closing bracket options.

7. Minor bugfixes and small improvements

How do you measure the performance of your own server or your clients'? Have you ever tried to compare the database speed of your Firebird server with new server hardware? Is a XEON Machine better than an Opteron? What improvements can you expect from fast SAS hard disks, RAID controllers or Enterprise SSDs?

The IBExpert Benchmark is a simple but effective tool, which gives you a reference benchmark, based on our recommended IFS Servers. Using IBExpert Benchmark you can generate and compare a reproducible speed index for your Firebird Server hardware. On average, our IFS servers with Firebird are 5 to 10 times faster than the server or virtual machines that our customers have previously used. 

Perform the comparison yourself using our free IBExpert benchmark software on your Firebird server: https://ibexpert.net/benchmark/setup_benchmark.exe

Read more

IBExpert Developer Studio at a Special Christmas Price!

We have a little surprise for you as the year draws to a close!

With this year's IBExpert Christmas Special, we're offering you the opportunity to expand your developer toolkit while saving money.

Our Christmas Offer

You can purchase as many licenses as you like at the special price whilst this Christmas offer is valid.

Who can benefit from this offer?

Whether you're equipping new developers in your company or expanding your existing IBExpert installation, our Christmas offer is attractive to both new and existing customers.

New Customers: All purchased licenses will be assigned to a single IBExpert User Account. Creating a second User Account for the same company and the same IBExpert product is not permitted.

Existing Customers: Additional licenses can be added to your existing IBExpert User Account, provided the associated Subscription is still valid. Here too, setting up an additional user account for the same company and the same IBExpert product is not permitted.

Your customers can benefit, too!

Don't forget about your own customers! They can also take advantage of our Christmas offer and purchase their own IBExpert Developer Studio licenses.

This allows your customers to use a full IBExpert license on their own hardware – for example, for remote support, maintenance tasks, or independent work with their databases.

That means both you and your customers can benefit from this year's Christmas Special!

Ordering and Payment Terms

Order processing depends on your company's location:

Promotional Period

December 1 through December 31, 2026

Please note: Full payment must be received no later than December 31, 2026, to qualify for the Christmas offer.

This offer applies exclusively to the purchase of new or additional licenses. Subscription renewals are excluded.

All other IBExpert license and usage terms remain unchanged.

We wish you a wonderful holiday season and thank you for your trust and continued cooperation!

Your IBExpert Team

German-language version

Why the order of write operations is so important for Firebird

Holger Klemt, September 2026

(PDF Download)

The reliability of a Firebird database does not depend on Firebird alone. It is equally important that the underlying operating system and storage system execute and acknowledge write operations in the way the database expects.

Firebird is designed to write changes to storage in a defined and carefully coordinated order. In particular, when Forced Writes are enabled, Firebird ensures that critical changes have actually been written to persistent storage before subsequent operations are considered successfully completed.

Caches and additional storage layers

Modern operating systems, RAID controllers and storage systems attempt to optimize write operations for performance reasons. For example, write operations may be collected, combined or passed to the physical storage device in a different order.

This is generally useful and usually unproblematic for normal file access. For a database system, however, it is essential that so-called flush or synchronization requests are reliably passed through all layers down to the actual persistent storage medium.

Additional layers between Firebird and the physical storage device can therefore become critical, for example:

• Host or controller caches
• RAID and storage virtualization
• Cluster file systems
• Block-level replication
• SAN or NAS systems
• Snapshots and other virtualization layers
• Write caches that are not protected by battery backup or flash-based protection

The problem arises in particular when one of these layers reports a write operation as completed even though the data has not yet been permanently stored.

What can happen during a crash

In the event of a power failure, kernel crash or hardware failure, write operations that have already been acknowledged may therefore be lost.

This becomes particularly problematic when a later database state has already reached the storage device while related earlier changes are still waiting in a cache. This can result in information within the database file that is no longer consistent.

Firebird’s carefully designed write strategy is intended to prevent exactly these situations. However, this requires the operating system, drivers, controllers and storage system to correctly implement the corresponding synchronization requirements.

Disabling Forced Writes may therefore significantly improve write performance, but at the same time it removes an important layer of database protection.

Linux Is not automatically protected against these problems

Linux file systems such as ext4 provide mechanisms for controlling the order and durability of write operations. However, this does not automatically mean that every underlying storage configuration provides the same guarantees.

As soon as additional cluster, mirroring, RAID or virtualization layers are involved, it must be ensured that flush operations and write barriers are actually passed through to persistent storage.

For database systems, the more important question is therefore not whether Windows or Linux is being used, but whether the entire storage stack reliably provides the guarantees required by the database system.

A real-world example

Several years ago, a serious failure occurred in a business-critical Firebird environment managed by us. The database was hosted on an externally implemented Linux cluster and storage solution.

Following an error, not only the production database but also the copy created at storage level was affected. Restoring the system required extensive analysis and repair work.

The architecture was subsequently changed. Since then, redundancy has no longer been provided through transparent mirroring of an open database file, but through replication at the Firebird database level to independent server systems. This architecture has been operating reliably in that environment for many years.

Redundancy should ideally be implemented at database level

For Firebird systems, we therefore prefer storage architectures that are as simple and transparent as possible.

Where possible, redundancy and high availability should be implemented in such a way that two independently operating Firebird servers each maintain their own local database file, with synchronization being controlled at the database level.

This approach offers several advantages:

• Each Firebird server controls its own database file.
• Storage problems affecting one system are not automatically transferred to the second database file.
• The number of additional caching and virtualization layers is reduced.
• Problems are easier to analyze and isolate.
• Firebird's write mechanisms, which are essential for data integrity, remain intact.

Security and performance are not mutually exclusive

Strictly maintaining the required order of write operations inevitably introduces a certain amount of latency. In applications with very intensive write activity, this latency can be clearly measurable.

However, this additional latency is not unnecessary performance loss. It is an essential component of transaction safety.

When optimizing a Firebird server, the goal should therefore not be to circumvent these safety mechanisms. A better approach is to design the hardware and storage architecture in such a way that synchronous write operations can be completed as quickly as possible.

A fast database requires fast storage. A reliable database, however, requires storage whose claims regarding successfully stored data actually hold true.

German-language version

Reliable, Near-Real-Time Synchronization for Mission-Critical Systems

Holger Klemt, August 2026

(PDF Download)

Modern applications increasingly require databases to remain available across multiple locations, servers, and environments. Whether the goal is high availability, migration from a desktop application to a web-based system, distributed databases, or continuous synchronization between data centers, reliable database replication is a critical component.

Our Firebird replication solution has been developed for precisely these scenarios. It combines transaction-safe replication, near-real-time synchronization, one-to-many replication, and support for large Firebird databases — while allowing replication to be introduced into an existing production environment without taking the database offline.

Designed for Firebird

The replication framework supports Firebird 2.5 and newer versions, including Firebird 4, Firebird 5 and current Firebird 6 databases.

A key advantage is that replication is implemented directly at the database level using active triggers and a transaction log. Changes made to the source database are recorded as transactions and can subsequently be transferred to one or more target databases.

This architecture ensures that changes are not lost simply because the network connection or replication process is temporarily unavailable.

Replication without production downtime

One of the most important requirements in a migration or high-availability project is the ability to activate replication without interrupting the running application.

Our replication process is designed for exactly this purpose.

Once replication is initialized, the required triggers begin recording INSERT, UPDATE and DELETE operations in a dedicated transaction log. The production database continues to operate normally.

The initial synchronization can then be performed by creating a backup of the master database and restoring it on the target server. This process can also be performed without taking the production database offline.

After the target database has been initialized, the replication process transfers all transactions that occurred while the backup was being created and subsequently continues with new transactions.

Transaction-safe replication

Reliability is at the heart of the architecture.

Imagine that the master database has accumulated 100 transactions waiting to be replicated. If the network connection fails after only part of the data has been transferred, the remaining transactions are not lost.

They remain in the transaction log and are transferred during the next replication operation.

The replication process therefore does not depend on a permanently available network connection. A target server can even be unavailable for days or weeks while the master database continues to collect the transactions required for synchronization.

When the target becomes available again, replication can continue from where it stopped.

One-to-many replication

The architecture also supports one-to-many replication.

A single master database can replicate its data to multiple target servers. Each target is tracked independently.

For example:

Master Server → Slave 1
Master Server → Slave 2
Master Server → Slave 3

If Slave 2 is temporarily offline, replication to Slave 1 and Slave 3 can continue normally. The transactions required for Slave 2 remain available on the master until that target reconnects.

This makes the architecture suitable for distributed systems where individual locations may have unreliable network connections or temporarily unavailable servers.

Multi-master replication

Depending on the database structure, the technology can also support multi-master replication.

In this configuration, several servers can act as master databases and exchange changes between one another.

However, multi-master environments require careful consideration of the database design, particularly primary-key generation. For example, automatically generated keys must be designed so that records created independently on different master servers cannot produce conflicts.

Where necessary, database metadata and application logic can be adapted to support this architecture.

Near-real-time synchronization

The replication process is designed for near-real-time operation.

In a typical environment, transactions are transferred continuously through a push/pull process. The actual latency depends on server performance, transaction volume and network conditions.

In one large distributed deployment, changes were typically visible at remote locations in less than 10 seconds. Even under periods of very high system load, latency generally remained within approximately one minute.

Locations with slower or unreliable Internet connections could continue operating locally. Once connectivity was restored, accumulated transactions were synchronized automatically.

Proven with large and distributed Firebird installations

The technology has been used in demanding real-world environments involving large databases and geographically distributed systems.

One particularly extensive project involved:

• 9 central servers
• 6 different data centers and cities
• Approximately 225 Firebird databases at individual locations
• Approximately 500 GB in the largest central database
• Around 2 billion records in the largest database
• Approximately 5–6 million INSERT, UPDATE and DELETE operations per day
• Near-real-time synchronization between the central systems and remote locations

The individual remote databases contained subsets of the central data and synchronized local changes back to the central infrastructure.

Despite unreliable network connections at some locations, the replication architecture ensured that transactions remained available until they could be transferred successfully.

Handling very large databases and BLOB data

Large Firebird databases can contain substantial amounts of BLOB data, particularly in applications such as healthcare, document management, imaging and archive systems.

In one implementation, the overall database environment reached approximately 7 TB, including transaction logs and annual BLOB databases.

For very large datasets, separating historical data into dedicated databases can provide significant advantages.

For example, annual transaction or BLOB databases can be closed and made read-only at the end of a financial year. They remain accessible via the main database, but no longer increase the size of the active production database.

This approach can significantly simplify and accelerate future backup and restore operations.

No single point of failure in the replication process

A temporary failure of a target server or network connection does not stop the master database from recording changes.

This is particularly important for distributed installations.

A remote server may be restarted, disconnected, or unavailable for an extended period. Once it becomes available again, the replication process can continue using the transactions that accumulated while it was offline.

The result is a replication architecture designed around reliable, post-event synchronization without data loss, which does not require all servers and network connections to be permanently available.

Database metadata plays a crucial role

Reliable replication starts with a suitable database design.

Ideally, every table that needs to be replicated should have a primary key or at least a suitable unique index.

Primary keys should also be reasonably compact. Extremely complex primary keys spanning a large number of columns can make replication and application development unnecessarily complicated.

Tables without primary keys may require an alternative identification mechanism. Depending on the database structure, a different technology based on Firebird's RDB$DB_KEY can be considered.

For complex environments, the database metadata can be analyzed before implementation to determine the most appropriate replication strategy.

Continuous replication with minimal maintenance

Once implemented, the replication system is designed to operate largely in the background.

In many installations, no regular manual maintenance is required.

Nevertheless, database administrators may occasionally perform extensive metadata changes or structural modifications that require replication to be reinitialized or adjusted.

For such situations, remote technical assistance can be provided through a prepaid support and hotline system. This allows administrators to request assistance when required rather than maintaining a permanent support contract solely for occasional replication operations.

Implementation and migration

Every replication project is different. Database size alone is not sufficient to determine the implementation effort.

Before a project begins, we therefore recommend analyzing:

• The database metadata
• Primary keys and indexes
• Database statistics
• Number and size of databases
• Transaction volume
• BLOB usage
• Network topology
• Number of replication targets
• Required replication direction
• Expected availability and recovery requirements

A metadata-only backup is often sufficient for the initial technical assessment. This allows the database structure to be reviewed without providing access to sensitive customer data.

Implementation and training can be carried out entirely remotely – even for customers in distant time zones.

Source code and customization

The replication framework can be delivered together with its source code, allowing customers to understand, adapt and integrate the solution into their own environment.

This is particularly valuable when replication forms part of a larger migration project, such as moving an existing desktop application to a web-based architecture while keeping the existing production system operational during the transition.

A practical foundation for system migration

Database replication is especially valuable when an organization needs to modernize an existing application without accepting prolonged downtime.

For example, a healthcare information system (HIS) and its associated image database may need to remain continuously available while the underlying application is migrated from a desktop architecture to a modern web application.

A transaction-based replication layer can provide a bridge between the existing and new environments, allowing both systems to operate while data is continuously synchronized.

This can substantially reduce migration risks and enable a controlled transition rather than a disruptive "big bang" migration.

A solution built on real-world experience

The architecture described here is not limited to laboratory scenarios. It has been used for more than a decade in demanding production environments with geographically distributed Firebird databases, large transaction volumes, unreliable network connections and substantial amounts of data.

The combination of transaction logging, trigger-based change tracking, push/pull replication and independent target tracking provides a robust foundation for high-availability and distributed Firebird environments.

For organizations planning a Firebird migration, high-availability project, distributed database architecture or near-real-time synchronization solution, the first step is a technical review of the existing database environment.

With the database metadata and current database statistics available, a realistic implementation plan, replication architecture and project-specific quotation can be prepared.