Real-time data replication to SAP SQL Anywhere from your operational databases

• ISVs and product teams whose applications run on SQL Anywhere and need reference, customer, or order data from a central system of record kept current in each database
• DBAs who want writes that respect keys and triggers, with duplicate keys handled by a per-entity setting instead of a load job that stops at the first error
• Platform leads who want one Core Hub for Oracle, SQL Server, PostgreSQL, MySQL, IBM i, and SAP ASE instead of one loader per source, backed by best-in-class enterprise support, rated 4.9/5 by customers
• Engineers replacing MobiLink scripts, nightly LOAD TABLE jobs, or custom ODBC loaders that fill SQL Anywhere, who want snapshots and monitoring built in

Keyed writes through the SAP JDBC driver

The agent connects through the SAP JDBC driver (sajdbc4) with a connection pool, and writes changes in batches, in the order of the stream.

• Inserts are INSERT statements.
• Updates and upserts are MERGE statements that update the row with the same key and insert it when it is not there.
• Deletes match the key of the row, including keys with NULL values.
• Duplicate keys by policy: a row refused for a duplicate key is handled by the entity's insert conflict strategy in Core Hub.
• Retries built in: statements that fail because a connection dropped or a row was locked are retried. SQL Anywhere target setup guide ↗

A bulk path with OPENSTRING, no staging table

For the highest throughput, turn on bulk operations per entity, for the snapshot, for CDC, or both. The rows of a batch travel to the server as one text parameter and a single statement reads them with OPENSTRING.

• New rows: a snapshot batch, or a batch of new rows, is one INSERT … SELECT from OPENSTRING.
• Changes: other batches are one MERGE from OPENSTRING, and deleted keys are removed with MERGE … WHEN MATCHED THEN DELETE. Updates stay updates, so triggers on the target table behave as they do with plain batches.
• One transaction: the statements run in the transaction of the write and commit together, with no staging table.
• Never a lost row: a batch the bulk path cannot carry is rolled back and written again with the plain batch statements.

Tables and types that look like SQL Anywhere's own

When a target table does not exist, Gluesync creates it from the source definition. A table you create yourself is written as it is, with the types it has.

• Text: NVARCHAR(n) by default, which counts characters on a UTF-8 database, and LONG NVARCHAR for long values; CHAR, VARCHAR, XML, and UNIQUEIDENTIFIER are available per column.
• Numbers: NUMERIC(p, s) with the source precision and scale, the integer types, MONEY, REAL, FLOAT, and DOUBLE.
• Dates and times: DATE, TIME, TIMESTAMP, and TIMESTAMP WITH TIME ZONE, with microseconds kept.
• Binary and spatial: LONG BINARY by default, and ST_GEOMETRY written from EWKB with its SRID.
• Pre- and post-commands: SQL commands per entity run before and after the snapshot and CDC tasks, as on the other SQL targets.

What your DBA sets up

The agent needs a user that can write the target tables, and the SQL Anywhere client on the Core Hub host. Full statements are in the SQL Anywhere target setup guide ↗.

1. Create a database user for Gluesync that owns the target schema, or grant it the ANY TABLE system privileges to create, alter, and truncate tables and to read and write them.
2. Install the SAP SQL Anywhere 17 client on the Core Hub host, or mount it into the Core Hub container at /opt/sqlanywhere17. Core Hub runs on Linux x86_64, or as linux/amd64, for this agent.
3. Open the database port to Core Hub, 2638 by default, and enter the host, database name, and credentials in Core Hub. Turn on TLS for the connection when the network calls for it.
4. Choose per entity whether the snapshot and CDC use the bulk path.

Architecture around Core Hub

Source agents sit close to each database, and Core Hub orchestrates them through its web UI and REST APIs. A pipeline groups a source agent with the SQL Anywhere agent and the tables it replicates, and pipeline state lives in Core Hub. Query Studio works on SQL Anywhere too, so you can query the target from the same web UI. Core Hub and agents deploy with Docker, Docker Compose, or Kubernetes. See CDC streaming for the wider pattern.

Explore the general CDC streaming architecture →

Any Gluesync source agent can feed SQL Anywhere. Open the integrations finder with SQL Anywhere pre-selected to see every source you can pair with it.

One Core Hub runs Oracle to SQL Anywhere, SQL Server to SQL Anywhere, and PostgreSQL to SQL Anywhere side by side, with the same snapshot, monitoring, and duplicate-key settings for each. Gluesync keeps pace with your change volume at any scale, and MOLO17 Professional Services can help plan the tables and the write path with your team.

• Oracle to SQL Anywhere from the redo logs: see Oracle CDC
• SQL Server to SQL Anywhere through Change Data Capture or Change Tracking: see SQL Server CDC
• PostgreSQL and MySQL to SQL Anywhere from the WAL and the binlog: see PostgreSQL CDC and MySQL CDC
• SAP ASE (Sybase) to SQL Anywhere from the ASE transaction log: see SAP ASE CDC
• SQL Anywhere to SQL Anywhere, one way or both ways, from the transaction log: see SAP SQL Anywhere CDC