SQL Server integration

Connect SQL Server business records with finance, customer and operational information in Uplyst's shared intelligence layer.

How change capture works
SQL Server change data capture

Connect ongoing database changes to the enterprise intelligence layer.

  1. Source tables

    Operational records

    Orders, transactions and other records committed in SQL Server.

  2. Change capture

    Inserts, updates and deletes

    CDC captures changes from the database transaction log.

  3. Change tables

    Ordered by log position

    Query functions expose the retained changes for consumption.

  4. Uplyst

    Business relationships

    Source records connect with finance, customer and operational context.

Capture latency measures how far CDC trails the source.

Processing latency measures changes still waiting to be applied.

Connect operational tables to business decisions

Approved SQL Server tables and views can bring order, inventory and financial records into Uplyst. Mapping source keys and relationships connects those records with information held in other systems, supporting fulfilment analysis, reconciliation and customer service.

Where change data capture is available and enabled, SQL Server records inserts, updates and deletes from selected tables in associated change tables. Capture instances describe the columns and keys available to a consumer. The deployed SQL Server or Azure SQL environment determines the supported configuration.

From retained changes to current business state

SQL Server exposes CDC changes within a log sequence number interval. Retaining the interval successfully applied to Uplyst provides a restart reference and makes processing progress visible.

Individual changes support a history of business transitions. Net changes, where supported, can suit a view of current state. The choice depends on whether a process needs the latest order status, the sequence of changes, or both.

RequirementDesign implication
Current order stateApply changes to a stable entity key
Audit of business transitionsRetain relevant individual operations
Restart after interruptionPersist applied LSN boundary
Changed captured columnsReview the capture instance contract

Freshness and recovery

CDC cleanup limits how long changes remain available. The next required change must fall within the retained interval for processing to resume without a gap. When required history has expired, a new snapshot and reconciliation restore current state; they cannot recover expired individual changes.

Capture latency and downstream processing latency describe different delays. Monitoring both makes the age of the resulting business information clearer.

Access limited to the required data

Capture administration and routine consumption can use separate identities. A consumer needs access to the captured columns and, where configured, membership in the gating role. Encrypted connections and scoped permissions keep sensitive data under the source owner's control.

Support changes to operational applications

New columns, changed data types and revised business keys can affect the captured data and its meaning. Updating the mapping alongside the source application helps preserve customer, order and financial relationships. Record counts and business totals provide a practical check after recovery or a schema change.

SQL Server CDC recovery compares the applied checkpoint and next required LSN with the retained source interval. An expired gap keeps restart pending a new snapshot and reconciliation.
Check the required LSN against the retained interval before resuming downstream processing.

Connect your systems
with Uplyst.

Talk with our team about the systems you use and the decisions they need to support.

Discuss an integration