Skip to Content
Technical Articles

Hana SDI Realtime Adapter for Azure SQL DB (and SQL Server)

A customer requested a Hana SDI adapter to replicate Microsoft Azure DB data to SAP Hana in realtime. In case you are in need of the same, feel free to contact me.

While SDI has an adapter for MS SQL Server, its driver is not compatible with the Azure SQL Server and even if, it needs access to the transaction log files which no user has.

Therefore we built a new SDI adapter using the official Microsoft technologies for change data capture, Change Tracking it is called.



  • Supports primary any standby databases: Queries and initial loads are then executed against the standby database and realtime change data capture happens via the primary database. If no standby database is configured, all queries go against the primary database.
  • Transactional consistency: Using snapshot isolation transactional consistency is preserved in Hana as well. What was one transaction in the source remains within one transaction in Hana.
  • Supports all data types: Special care has been taken to support all SQL Server data types and to map them to the correct Hana data types.
  • Follows the SDI architecture to the letter: No information is stored in SQL Server, SDI provides the restart points in case of error recovery and the such. Hence it does not have limits like only one SDI agent connected to a single SQL Server database.
  • Supports Azure and on-Prem SQL Server databases.
  • Pushdown is supported but basics only: Where clauses, projections and everything else needed for efficient initial loads but e.g. no pushdown of functions.
You must be Logged on to comment or reply to a post.
  • Hi Werner,

    Why did you base it on change tracking and not on triggers? Less impact on the source / no need for full change history? SDI has recently added trigger support for some formerly log-based only databases.



    • Hmm... why does the change tracking create more impact than triggers? From what I understand of the documentation, the mechanics seem very similar (store the primary keys of changed records in some other data structure). What's making the triggers the better option here?



    • My impression as well (like Lars Breddemann), it has virtually no negative impact on the operational system performance. And from the consumer side looks and feels like a trigger based solution except you do not have to deal with maintaining the triggers, make sure the log tables are emptied once a while, no log tables to be created, benefit from internal optimizations, etc.

      I have been quite impressed with the feature. Well done, Microsoft.



      • Somehow I missed your reply and only now I'm reading it as I was searching for something else. For what it's worth: I actually didn't mean to say triggers would have less impact than your solution, instead I meant to ask "did you choose this solution because it has less impact on the source than triggers"? And you already answered that question ;-).

  • Hi Werner,

    Thanks for your post.

    I would like to know if this SDI adapter or any other  supports replication from HANA DB to Azure DB .

    • That would need two functionalities:

      • Identify changes in Hana
      • Insert/update/delete/truncate of virtual tables

      Both exists only in parts. You cannot create a remote subscription in a Hana table, it has to be a virtual table. So you would need to configure in Hana a virtual table that points to itself.

      And while DML operations on virtual tables are possible, SDA/SDI has not been optimized enough for that.

      And finally, the main advantage of SDI to have batch/replication/datafederation in one place would not be utilized.

      Therefore I use other solutions for a use cases like that.