Comparison sheet

Several replication tools are compared to each other, both on architectural en configuration aspects. 

The contenders: 

  • SQL Remote. This is a product from Sybase and comes in two flavors, ASE and ASA. ASE stands for Advanced Server Enterprise, the Sybase flagship server, ASA stands for Advanced Server Anywhere, an entry level server, specially designed for mobility. Support for ASE SQL Remote is discontinued in 2006.
  • Fibre. Fibre icon-external-link.pngstands for Firebird Replicator created by R.J.Munro. It is a Open Source Java tool, solely working on Firebird (as the name suggests). According to Sourceforge data, the Fibre project looks dead.
  • IBReplicator. IBReplicator icon-external-link.png is a closed source commercial replication tool, written first for Interbase (IB stands for Interbase), the predecessor of Firebird. But because the API's of Interbase and Firebird are interchangeable, IBReplicator works also for Firebird.

info.png Fibre, IBReplicator and Frext could be compared directly because they all work on Firebird, as opposed to SQL Remote. SQL Remote (as to be expected) only works on Sybase databases, so there's no chance using this product for Firebird; so, the different products are not interchangeable, because they work on different database servers. Despite this, the comparison has been done, just to point out the many technical disadvantages of SQL Remote which I like to overcome, all in the context of my history on making Frext.

info.png Please let me know with any systems I have missed, or corrections to my analysis. This is not intended to promote Frext, but as an objective comparison to allow you to decide which system to adopt.

  Frext SQL Remote Fibre IBReplicator  
Open Source Yes No Yes No  
Cross-platform Yes Yes Yes Yes/No Frext and Fibre are written in Java; SQL Remote has native clients for Linux and Windows; the GUI administrator of IBReplicator runs only on Windows
Message based Yes Yes Yes No IBReplicator needs direct database contact; as such, IBReplicator is not suited for mobile solutions
File messages Yes Yes Yes No IBReplicator contacts database directly; therefore implicitly no file messages possible
Transparent message processing Yes No Yes - SQL Remote makes use of binary files while providing no additional viewer tools. Frext and Fibre both uses plain XML files. IBReplicator does not replicate by messages (files).
Mail/FTP messages  Yes Yes Yes No Frext and Fibre support mail and ftp implicit, not natively; Frext and Fibre must be extended with scripting tools which take care of mailing or sending messages through ftp. SQL Remote has native mail and FTP support. IBReplicator requires direct database contact, other channels are implicitly not possible
Multiple message channels at the same time Yes No Yes - Because Frext and Fibre only have one channel (file), others like mail/FTP can be flexible added 
Asynchronous replication Yes Yes Yes Yes
Synchronous replication Yes No No No  
Configuration by GUI Yes Yes No Yes SQL Remote configuration depends on Sybase Central. GUI configurator for IBReplicator only works on Microsoft Windows.
Configuration by file Yes No Yes No File is in XML format for both Fibre and Frext. Fibre needs an extra configuration file (SQL script) for changing the structure of productions tables.
Configuration by SQL Yes Yes No No Fibre doesn't keep configuration settings in the database but relies on an external configuration file
Loosely definable replication model Yes Yes No No Fibre and IBReplicator require exact configuration (login data, location, etc.) of all other databases involved
Transaction based Yes Yes Yes Yes SQL Remote uses the built in transaction log from ASE or ASA. As Firebird/Interbase does not have a transaction log, Frext, Fibre and IBReplicator have to build up a (custom) pseudo transaction log.
Transaction log viewer Yes No Yes Yes SQL Remote or the databases it works on (ASE, ASA) does not provide any viewer to analyze the built in transaction log. As Frext, Fibre and IBReplicator uses a pseudo transaction log, it can be easily analyzed, even with standard tools like ISQL. Log viewer for IBReplicator is built in the GUI administrator.
Operations executed in original order Yes Yes No Yes Fibre groups operations per type, i.e. first inserts, then updates and then deletes.
Transaction grouping &  execution Yes Yes No Yes Fibre doesn't have any knowledge about transactions; operations are logged, but are not registered by a transaction number.
Table sequence independent Yes Yes No Yes Fibre executes operations based on user defined table sequence which is very error prone. For inserts/updates and deletes, the opposite sequence is followed to prevent foreign key violations.
Resend messages Yes Yes No - Fibre registers which message is expected, but provides no resend mechanism. IBReplicator does not rely on external messaging, e.g. files thus has no need to resend messages.
No modification of production table structure Yes Yes/No No No/Yes

Fibre depends on a predefined key field; this field must be present in every table which must be replicated; this field is filled by a generator to provide unique values; table alteration is done by a separate (user definable) sql script.
When using SQL Remote in combination with partitioning on a ASE database, tables involved must undergo a table structure change, see "Automatic partitioning on sub tables".
Frext requires an extra trigger on each replicated table but the table it self is unchanged. IBReplicator needs a timestamp field for solving update conflicts.
Built in data extract Yes Yes/No No No Extracts for SQL Remote only work for ASA, when using ASE, you are on your own. Fibre nor IBReplicator does not have any extract mechanism.
Automatic extract processing Yes No - - Frext handles extract messages exactly the same as normal replication messages. An extract message is just another message for Frext and can even be requested by the remote. SQL Remote requires DBA or user interaction.
Partitioning Yes Yes No No Documentation of Fibre indicates that there is some kind of partitioning possible. However, no example for partitioning is giving, nor does the documentation indicate how this can be configured. Also, reviewing documentation show a (possible) design flaw for implementing partitioning: all operations for all partitions will always be transferred, the remote it self is responsible for filtering. This method does not provide a solution for partitioning realignment.
Automatic partitioning on sub tables Yes No - - SQL Remote depends on partitioning clauses. For each sub table the clause must be manually configured. The complexity of this clause is growing exponentially by each added table dependency level. Also, defining such a clause for an ASE database is subject to severe limitations. If all partitioning functionality is needed on an ASE database, table structure change in inevitable.
Automatic partitioned data extract Yes No  - - SQL Remote requires compiling each partitioning clause (per table), which is a rather complex task. As indicated earlier, extracts only works for ASA.
Automatic partitioning realignment Yes No - - Realignment within SQL Remote must be manually configured through triggers
Field level replication Yes Yes No Yes
Simple table replication (no field info given) Yes Yes - No With IBReplicator, each replicated field has to be configured; Frext and SQL Remote conclude that when there's no field info, the whole table must be replicated
Field level replication, by exclusion Yes No - No SQL Remote and IBReplicator only have an inclusion options. This means that if you want to replicate the whole table except one field, you have to enumerate all other fields. This is an error prone and time consuming process.
Auto key field detection Yes Yes - No Fibre depends on a (custom) identification field, specifically added for Fibre; Fibre works exclusively with this field, the 'real' key fields are ignored. With IBReplicator, each key field has to be configured
Centralized system logging Yes No No Yes SQL Remote provides a standard log file, Fibre provides XML-messages 'done' as confirmation. Both files stay on the remote and are thus not viewable on a central point. Frext replicates log data back to the sender.