NB: earlier, SAP Advanced SQL Migration was called ‘Exodus’. it was renamed in Q4 2017. This blog post will be updated soon.
One of my professional frustrations is that most non-IT people don’t seem to care about things that I find interesting.
For example, rarely do I meet interesting people at a party who don’t walk away when I start talking about the fascinations of converting one SQL dialect to another. I mean, are there really that many topics that are more fascinating? (okay, I admit I’ll bow to string theory, nuclear fusion, and why it’s so much harder to loose weight when you’re over 45 years old).
For the SAP Exodus project, we needed to find a way to demonstrate what it was that we were trying to do. That ain’t easy: I mean, when you migrate an application from one DBMS to another, then what do you get? Well, initially you had an application that was working fine…. and after it was migrated it is still working fine, except on a different database. For some reason, many people find that boring (as I mentioned earlier, this SQL migration stuff gets me really excited — but I guess that just says a lot about me). So how can we make this more visible?
Finally, I think we found a way to show what we’re trying to do.
Below is a link to a video recording of a demonstration of the SAP Exodus DBMS migration tool.
The video shows a 2-tier, stored-procedure-based, transactional client-server application. The application is for a publications database, with entities like authors, titles and publishers (for those with a Sybase background: it’s loosely modeled on the ‘pubs2’ database). There’s some 2000 lines of PL/SQL involved.
The following steps are demonstrated:
- The video first demonstrates how the application works on an Oracle database, and how for example Oracle PL/SQL exceptions are used to handle error conditions.
- Then, Exodus is run against the Oracle application. Exodus extracts the schema and all stored procedures, functions and packages from the Oracle server, and converts these to the Transact-SQL dialect for SAP ASE.
- The generated SQL code for creating the schema is executed against an SAP ASE server, and so are the converted SQL objects (e.g. stored procedures, packages, etc.)
- The data is copied from Oracle to ASE (using the former Sybase DirectConnect product)
- The client application is disconnected from Oracle and reconnected to ASE, and,magically, the application works exactly the same, including the handling error conditions (despite ASE not having an exception mechanism like Oracle — see here for more examples of things that may seem impossible).
The real important point in this demo is that no changes had to be made to either the generated SQL code or the client application: Exodus performed a 100% correct and automatic conversion from Oracle to ASE (admittedly, things may not be 100% correct and automatic when we would run Exodus against a real-life customer application, but hey, that’s why it is a demo: to show what is potentially possible).
Now, watch the demo here:
If you’re a customer and you’re interested in exploring how to migrate custom applications away from Oracle, MS SQL Server or DB2, contact ExodusHelp@sap.com to discuss how SAP can help.
If you’re an SAP Partner Edge partner and you would like to get a copy of Exodus to use in migration projects with your customers, contact ExodusHelp@sap.com as well.