Quo Vadis SQL Anywhere?

VSQL Anywhere, im Folgenden kurz ASA genannt, war in der Vergangenheit eine beliebte Wahl für Applikationen, deren Backend SQL gestützt sein sollte. Wir im Hause Fischer & Consultants waren von dem Produkt sehr überzeugt und haben es für viele unserer Kundenprojekt eingesetzt. Im Laufe der Jahre haben wir dann auch den Vertrieb der ASA übernommen, das ist jetzt vorbei!

SAP hat uns den Vertrag, der den Verkauf von Lizenzen regelt, zu Ende 2025 gekündigt. Des Weiteren haben sie angekündigt, das Ende 2027 für die ASA das ‚end-of-life‘ gekommen ist.

Ein klein wenig Historie

Werfen wir einen Blick in die Entwicklung der ASA:

  • 1992: Die Firma Watcom veröffentlich die erste Version „WatCom SQL“ V3
  • 1993: Watcom wird von Powersoft übernommen
  • 1995: Sybase kauft PowerSoft und nennt das Produkt fortan „SQL Anywhere“ (Version 4)
  • 1998: Umbenennung in „Adaptive Server Anywhere“ (Version 6)
  • 2005: Erneute Umbenennung in „SQL Anywhere“ (Version 10)
  • 2008: Version 11 veröffentlicht
  • 2010: SAP übernimmt Sybase – Version 12 veröffentlicht
  • 2013: Version 16 veröffentlicht. Die Versionsnummer 13,14 wurden aus kulturellen Gründen übersprungen ( 13 gilt in den USA und Europa als Unglückszahl, 14 in China). Mit dem Sprung auf 16 erfolgte zudem die Angleichung der Versionsnummer verschiedener Produkte.
  • 2015: Version 17 wurde veröffentlicht.
  • 2016: Die Varianten „Standard“ und „Workgroup“ wurden vom Markt genommen und die „per CPU“ Lizenz wurde durch „per Core“ ersetzt.

Aktuell sind alle früheren Versionen ausgelaufen und werden nicht mehr unterstützt. Lediglich die Version 17 wird nach wie vor gepflegt und es werden noch regelmäßig Bugfixes (EBF’s) veröffentlicht, wenn auch mit größer werdenden Abständen. Schaut man sich die Dokumentationen zu den EBF’s der Version 17 an, fällt auf, dass es sich im Wesentlichen um Bugfixes handelt, notwendigen Anpassungen an die aktuellen Erfordernisse im Sicherheitsbereich, selten um neue Features und Verbesserungen. Wir arbeiten also mit einem Produkt, dass seit knapp 8 Jahren weitestgehend unverändert daherkommt. Warum das eines der Kernprobleme ist, werden wir später noch beleuchten.

ASA Features

Warum ist (war) die ASA so beliebt? Nun, ein Blick in die Features des Produktes hilft bei der Beantwortung der Frage (wir lassen hier Ultralite und Mobilink bewusst außen vor):

  • Vollständiges Relationales Datenbank Management System (RDMS)
  • Kann sowohl lokal als auch auf einem Server eingesetzt werden
  • Performant
  • Kleiner Fußabdruck
  • Leichte Installation lokal und auf Server
  • Stabil und sicher
  • HA-Option für Ausfallsicherheit und Verfügbarkeit
  • Verfügbar auf diversen Plattformen
  • Anbindung über einen reichhaltigen Satz von Treibern
  • Leichtes Handling von Datenbanken, durch ein plattformübergreifendes Dateiformat. So können DBs durch einfaches Kopieren von Dateien auf andere System transferiert werden.
  • In-Memory Betriebsart
  • Automatisches Caching
  • Großzügige Limits (z.B. max. DB Größe ) Diese sind nur die wichtigsten Merkmale. Dazu kommen noch die implementierten Funktionalitäten, neben denen eines RMDBS:
  • Java in the database: Erweiterung der DB Funktionalitäten durch eigene Java-Klassen
  • Direkte Unterstützung von Web-Applikation durch in SQL implementierte http Endpunkte und integrierten http Server.
  • Konsumieren von http Endpunkten in SQL Code
  • Einfache Implementierung von Odata Endpunkten
  • Erweiterung des SQL Sprachstandards durch ASA-eigene Sprachkonstrukte, die es dem Programmierer die Arbeit vereinfachen
  • …

Hört sich alles doch ganz gut an, oder?

Die Zukunft ?

So wie es sich momentan darstellt gibt es für die ASA keine Zukunft. Ab Ende 2025 werden keine weiteren Lizenzen mehr verkauft und Ende 2027 wird es keine Updates mehr geben. Tag heute gibt es auch kein Nachfolgeprodukt seitens SAP, welches die ASA Datenbanken und deren Features zur Verfügung stellt. Warum stellt dies ein Problem da, das Produkt läuft doch?

Viele Firmen, gerade größere, international tätige, haben sehr strenge Regeln, was die Nutzung von Software angeht. Produkte die nicht mehr gepflegt werden und deren Ende bevorsteht, landen sehr schnell auf der schwarzen Liste und müssen ersetzt werden. Ein Datenbanksystem durch ein anderes ersetzen? Ähnlich einer Scheidung kann das richtig teuer werden. Bei allen Vorteilen und Bequemlichkeiten, die die ASA mit sich brachte, sind es genau diese Merkmale, die uns Probleme bereiten. Vieles wird von anderen Systemen nicht oder auf eine andere Art & Weise unterstützt. Es ist also Arbeit angesagt, die ordentlich Zeit und Ressourcen beanspruchen kann. Jetzt kann man argumentieren, dass 3 Jahre ja reichlich Zeit sind, aber das ist zu kurz gedacht. Im Grunde sind es nur noch 1.5 Jahre, denn wenn wir keine Lizenzen mehr erwerben können um unsererseits Produkte zu verkaufen, dann braucht es spätestens dann Alternativen.

Es sei noch ein weiterer Punkt angeführt, warum es Zeit ist zu handeln und zwar jetzt. Die Programmierung im Microsoft Kosmos, hat sich rasant verändert. So werden heute Lösungen, die mit einem RDBMS Backend kommunizieren, zum überwiegenden Teil mit Entity Framework realisiert. Für die Arbeit mit der EF Infrastruktur braucht man entsprechende Treiber, die es bis zur Visual Studio Version 2015 auch noch gab. Danach? Fehlanzeige.

Mit der Verfügbarkeit von .Net 6.0 ist es möglich auch .Net Programme für Linux Systeme zu schreiben und laufen zu lassen. Dadurch lassen sich plötzlich auch Dinge wie Docker mit unseren Programmen sinnvoll nutzen. .Net Treiber für die ASA? Lange Zeit gab es nur die Aussage, gibt es nicht und wird es auch nicht geben. Mit einer der letzten Versionen der 17er gab es dann plötzlich doch einen, aber leider nur für den Einsatz unter Windows. Windows Docker Container sind zwar möglich, aber kein Spaß und sehr ressourcenhungrig …

Die kommenden Aufgaben

Viele der auf uns zukommenden Aufgaben und Lösungen hängen von der Wahl des zukünftigen Datenbanksystems ab. Wir können hier nicht alle möglichen Alternative beleuchten, deshalb beschränken wir uns exemplarisch auf Microsoft Sql Server als Zielsystem.

Welche Aufgaben kommen auf uns zu und mit welchen Problemen müssen wir rechnen?

Datenbankschema übertragen

Man sollte meinen, das das Übertragen des DB-Schemas (Tabellenstrukturen, Index-Definition, Defaults, Integritätsbedingungen etc. pp.) völlig problemlos möglich sein sollte. Dem ist aber nicht so. Mal abgesehen von syntaktischen Feinheiten, gibt es auch andere Fallstricke. So erlaubt die ASA beispielsweise die Definition eines Primary Keys auf eine long varchar Spalte, die MSSQL aber nicht. Ob das ASA Verhalten sinnig ist oder nicht sei mal dahingestellt.

Daten übertragen

Nachdem wir jetzt das DB Schema übertragen haben, geht es an die Übernahme der Daten. Auch diese Aufgabe ist nicht ohne Probleme. Schwierigkeiten Datentypen aufeinander abzubilden, doppelte Schlüssel (wie das sein kann sehen wir uns im nächsten Blog Eintrag an) … um nur ein paar zu nennen.

Views, Functions, Stored Procedures

Die ASA bringt einige Eigenschaften mit sich, die es in anderen Systemen nicht gibt. Diese müssen adressiert und umgesetzt werden. Hier ein paar Beispiele bezgl. MSSQL:

  • User Defined Function dürfen keine DML Befehle auf reguläre Entitäten enthalten. Das führt u.U. dazu, dass Functions zu Stored Procedures umgebaut werden müssen und das hat möglicherweise Auswirkungen auf der konsumierenden Seite (Client)
  • Die ASA kennt das Prinzip der Default-Parameter. An der aufrufenden Stelle übergibt man nur die bekannten Parameter, die anderen werden automatisch von der ASA mit ihren Default-Werten ergänzt. Solche Aufrufe sehen auf der MSSQL anders aus, dort muss das Schlüsselwort DEFAULT and den fehlenden Stellen übergeben werden. Zudem lässt die MSSQL als Defaultwerte nur Konstanten und keine Funktionsaufrufe zu.
  • Das FOR Statement gibt es so auf der MSQL nicht und muss anders umgesetzt werden. Die ASA stellt implizit Variablen für die bezogenen Spalten zur Verfügung, die müssen auf der MSSQL explizit angelegt werden. (Es gibt da durchaus noch weitere Implikationen)
  • Cursor Definitionen können keine Resultsets aus Prozeduren nutzen
  • Die ASA hat einige, teilweise als depricated gekennzeichnete, Befehle, die aber immer noch unterstützt werden, aber auf der MSSQL nicht zur Verfügung stehen: =, =, natural join, key join …
  • Der Umgang der ASA mit Datumstypen und Integer ist zwar bequem aber auf der MSSQL nicht zulässig. z.B: Birthday+1 (date+integer) quittiert die MSSQL mit einem Fehler.
  • Eines der Dinge, die bei der ASA sehr einfach sind und viel gebraucht: Aliasierung von Spalten und Verwendung dieser Aliases in anderen Spalten, Where-Klausel, Order By Klausel, etc. Dies geht in MSSQL nicht so einfach wie auf der ASA.

Dies ist nur eine kurze, beispielhafte Liste, eine komplette würde diesen Rahmen sprengen.

Java-In-The-Database

Gerne benutzt um die DB mit Funktionalitäten zu erweitern, die so nicht, oder nur unter Wehen, zu implementieren sind. In MSSQL gibt es das nicht. Erweiterungen gehen in Form von .Net Komponenten, aber spätestens wenn man auf eine in der Cloud gehostete Instanz (z.B. Azure Sql) gehen will, fällt das meistens aus.

HTTP/OData Endpunkte

Mit der ASA ließen sich HTTP und OData Endpunkte direkt implementieren. Diese Funktionalität wird von MSSQL nicht unterstützt.

Web-Aufrufe aus Stored Procedures oder Funktionen

In der ASA kein Problem, bei anderen Datenbanksystem sehr wohl. Meistens hört man dann, dass das aus Sicherheits- und Stabilitätsgründen nicht umgesetzt wird. Interessanterweise gibt es diese Funktionalität bei der aktuellen Azure Sql Variante, hier ist vielleicht Besserung in Sicht.

Man sieht schon, obwohl nur ein kleiner Überblick, die Liste der Aufgaben wird recht lang und die Aufgaben selbst u.U. recht komplex. Eine gute Planung, ausreichend Ressourcen und genügend Zeit sind für mich die Schlüssel für eine erfolgreiche Umsetzung.

QS bei der Migration

Hat man sich zur Migration auf ein anderes System entschlossen, kommt viel Arbeit auf einen zu. Ein paar Dinge sollte man dabei nicht außer Acht lassen:

  1. Ständige QS durch Unit-Tests: Wir müssen sicherstellen, dass unser Code die gleichen Ergebnisse liefert wie das Original-System
  2. Diese Test müssen schon auf dem Alt-System entwickelt werden !
  3. Der Migrationsprozess wird an einigen Stellen nicht optimalen Code zu Tage fördern. Nehmen Sie diesen Input, um das Alt-System zu verbessern!

Insbesondere der letzte Punkt liegt mir am Herzen. Der Migrationsprozess ist sowieso iterativ, da es Probleme gibt, die im Original gefixt werden müssen(!), wenn man nicht einen sehr aufwendigen manuellen Prozess etablieren will. Schaffen Sie zum Beispiel im Originalcode die Verwendung von nicht kompatiblen Ausdrücken ab, wird der transportierte Code sehr einfacher und besser lesbar. Entdecken Sie Performance Probleme, werden Ihre Anwender es Ihnen danken, wenn Sie diese, mit den neu gewonnenen Erkenntnissen, auch im Alt-System bereinigen.

Sollte dieses Thema Ihr Interesse geweckt haben, nehmen Sie gerne an unserer diesjährigen Konferenz, den TechDays 2024, teil. Weitere Informationen dazu finden Sie unter www.appfact.de/konferenz.

Demnächst: Von Sql Anywhere zu Microsoft Sql Server Part I : DB-Schema und Datenübertragung