Author: jonneve

[See remaining text…] 

* [FB only] Tracking of changed fields. This feature will be added to other database types in future versions.

– Added intelligence to the triggers in order to detect and log the full list of changed fields and their values, rather than merely the primary key. This new option is activated by the TCcConfig.TrackFieldChanges property (the old mode can still be used.

– An associated option was added to TCcReplicator, OnlyReplicateChangedFields. If this option is set to true, then the changes will be replicated exactly as they occured, with no bunching of records, and replicating every time only the fields that were changed. In terms of performance, the new mode will be better for some situations (particularly tables with many fields or with blob fields, as those fields will only be sent over the wire when they actually change, rather than every time the row was touched.

– This new mode also allows improved consistency, as there should never be any foreign key violations (sometimes inevitable with the old system, due to record bunching), which means that it becomes possible (and recommended) to run the whole replication cycle within a single transaction, and to rollback if an error occurs.

* [FB only] Improved conflict management. This feature will be added to other database types in future versions.

– Thanks to the new field change tracking, finer conflict management is now possible. A new property TCcReplicator.MergeChangedFieldsOnConflict allows many conflicts to be automatically resolved by merging the changes from both nodes, in cases where none of the same fields were changed on both sides. In cases that are still conflictual, the OnResolveConflict event and the RPL$CONFLICTS table provide the list of fields changed on each side as well as the list of fields changed on both sides, and it is also possible to find out for each field the value that it was changed from and to on each side, making conflict resolution much easier.

– If the TCcReplicator.MergeChangedFieldsOnConflict property is set to True and a conflict is detected, the fields that were changed on only one of the nodes will be merged. For instance, if the first node changed fields A, B and C while the seconde node changed fields C and D, if the conflict is resolved in favor of the second node, the values of A and B from the first node will be kept, as they were not conflictual with the change from the second node. Thus, conflict resolution can be much finer-grained.

– This option depends on the TCcReplicator.OnlyReplicateChangedFields property being set to True, as it doesn’t make any sense without it.

– Added support for FreePascal/Lazarus

– New Direction property added to TCcReplicator enabling various performance optimizations when replicating only one way.

– Fixed bug in NexusDB support causing replication to fail on tables with multi-segment primary keys.

– Fixed bug causing MS SQL Server replication to fail on newer versions in tables containing an identity field.

– Added conditional replication support to SQL Server

– Fixed bug causing conflict management to fail under SQL Server

– Added SQL server support to UniDAC.

– Fixed bug causing TCcLog.LineCount property to increment twice for every row

– Fixed bug causing replication over transport layers to fail with error “Invalid parameters for call to function 10”

– Fixed bug in FIBPlus connector causing an access violation upon destroying the connector

– Various other minor bug fixes

« Hide it

[See remaining text…] 

CopyCat v3.04.0 (4th of April 2013)

TCcReplicator

• Fixed a bug whereby empty string values were sometimes changed

into nulls.

• FIBPlus connector : improved recovery after connection loss :
  sometimes connection would not resume correctly after network error was
  fixed.
• CopyCat now checks the number of rows affected by either the
  update or insert into the destination database and raises an error if
  ever neither the update nor the insert was successful.

CopyCat V3.03.0 (1st of August 2012)

• New database adaptor for SQLite
• XMLRPC server and CopyCat transport server for iOS (written in
  objective-C, compatible with Delphi CopyCat XMLRPC transports.

• Added AutoCommit property on client transport. Setting
  autocommit optimizes communication by not explicitly starting nor ending
  transactions. This implies that the server side must automatically
  commit after executying every query.
• Added property EncodeStringsAsBase64 to TCcRtcClientTransport
  and TCcRtcServerTransport.

• Added parameters TableName and Fields to OnRowReplicated
  event, allowing to access the table name of the row just replicated, as
  well as the values of the fields transfered.
• Added parameters ReplicateRow and AbortAndTryLater to the
  OnRowReplicating event. If ReplicateRow is set to false, the row is not
  replicated and the row is discarded from RPL$LOG. If AbortAndTryLater is
  set to true, replication of the row is aborted, and will be tried again
  next replication cycle (ie, the row is left in RPL$LOG).
• Renamed OnAbort event OnReplicationAborted. It it called only
  when replication is explicitly aborted via the AbortReplication method
  or by setting CanContinue to false in the OnReplicationError event.
• Added property TrimCharFields. If set to True, TCcReplicator
  will trim all char, varchar or memo fields that are read from the source
  database before replicating them to the destination database.

• Added multi-configuration abilities. This means that multiple
  replication configurations can be created for the same database,
  allowing separate lists of tables, replication conditions, and
  replication nodes to be configured independantly from each other.
• You can now define replication configuration at design time,
  using the new Tables property. Double-clicking on this property allows
  you to define the list of tables to replicate for the current
  configuration (defined by the ConfigName property), along with the
  conditions for each, as well as the list of nodes to replicate towards
  (corresponding to the RPL$USERS table). You can then roll out this
  configuration at run time by calling the GenerateConfig property. This
  will create triggers for all the tables defined in your configuration,
  or recreate them if any of the configuration options has changed. If you
  want to define several replication configurations, then you need one
  TCcConfig instance for each configuration.
• New IncludedFields property in the Tables list allows you to
  specify the list of fields to include in the replication triggers. This
  means that the change will only be logged for replication (in RPL$LOG)
  if at least one of the included fields has changed. Thus empty updates
  or updates of fields that are of no interest to the replication config
  can be excluded, thereby lightening the replication load. If no
  IncludedFields are set, the default is to include all fields, as before.
• New IncludedFields property in the Tables list allows you to
  set a list of fields to exclude from the replication triggers. This is
  just a shortcut for adding all but the fields specified to the
  IncludedFields list.
• New procedure RPL$FORCE_REPL allows to force replication of a
  certain set of rows, within the context of a certain config. This can be
  useful when the IncludedFields property is used.
• Added multiple data types in order to handle all the new
  TDataType values. This fixes a bug that occured with some Firebird
  dialect 3 datatypes, when replicating over XMLRPC or RTC transports.

« Hide it