We just started to test a new Bi-Directional and Read Only replications that will be added in a new database release.

The bi-directional replication resolve conflicts in a column level. For instance, if both subscriber and publisher modify the same row, but different columns, the changes will be merged to a single row. If modified the same column, the conflict will be not resolvable and it will be logged to a conflicts table for the user action. When a conflict occurs, for each conflicting row, 3 rows will be present. 2 rows from subscriber: original row since the last synchronization and the latest one. And 1 the newest from publisher.
If a column has been incremented/decremented by numeric value, for example "Amount" or "NumberOfItems", it could be possible to apply delta changes from subscribers to publisher and avoid conflicts.

The synchronization process is transactional, i.e. if user application aborts replication or unexpectedly exists, the merge changes will be rollback in both subscriber and publisher.

Publisher can synchronize with many subscribers. In addition, subscriber has an option to subscribe to a set of rows from the table with a filter (where clause) condition. Publisher can be distributed DB or Server and subscriber - Server or EmbeddedDB.

We have published alpha version available at: http://www.scimore.com/download/3.0/ both server and embedded. Try it!

To subscribe the table, execute on subscriber DB following command:

subscribe from 'dev21:999'
(
merge test.testconflicts to test.testconflicts,
merge webstats.geoip to test.geoip
)

Where: 'dev21:999' - publisher, test.testconflicts & webstats.geoip - tables on publisher, test.testconflicts & test.geoip - subscribed tables(these tables will be automatically created).

When you subscribe first time, the command will tell to publisher to initialize tables for publishing and subscribe. The second subscriber will only subscribe to already published table, so it will execute faster.

To unsubscribe, execute in the same format as subscribe command, except change command name to unsubscribe:

unsubscribe from 'dev21:999'
(
merge test.testconflicts to test.testconflicts,
merge webstats.geoip to test.geoip
)

Unsubscribe command will remove information from publisher about the current subscriber and drop the local subscribed tables in subscriber.

To synchronize, execute:

synchronize test.testconflicts with test.testconflicts on 'dev21:999'

OR

synchronize test.geoip with webstats.geoip on 'dev21:999'

The command will merge the changes from both subscriber and publisher.
NOTE: when you execute this command in manager or with .NET provider the conflicts will not be resolved. The command will return an error and abort synchronization.
A conflict appears:
1. UPDATE DELETE - one deleted, other updated.
2. UPDATE UPDATE - both updated the same column. If each updates different columns, sync merges the changes and applies it.

The conflict resolution is possible with the .NET provider new classes for replication.

If you replicate big tables, it may take time when subscribing, you could increment number of DB cache pages to 10.000-100.000 so it will run much faster. The default is 3000 pages where each takes 8KB.