English Version: sqlbase2db – The structured way out of Gupta SQLBase

Automatisierte Migration von Gupta-SQLBase-Datenbanken nach Microsoft SQL Server, PostgreSQL, MySQL und MariaDB – inklusive Struktur, Views, Daten und Indizes. Lokal. Reproduzierbar. Ohne manuelle Strukturarbeit.

Gupta SQLBase läuft in vielen Unternehmen seit Jahrzehnten stabil – das ist nicht das Problem.

Das Problem beginnt dort, wo moderne Anwendungen, aktuelle .NET-Architekturen, flexible Datenbankplattformen und wirtschaftliche Lizenzmodelle gefragt sind.

sqlbase2db hilft dabei, bestehende SQLBase-Datenbanken sauber in moderne Zielsysteme zu überführen – ohne wochenlange manuelle Fleißarbeit an Tabellen, Datentypen, Views, Datenexporten und Indexdefinitionen.

Zielsysteme aktuell:

• Microsoft SQL Server
• PostgreSQL

Weitere Zielsysteme sind fest vorgesehen:

• MySQL
• MariaDB

Die Unterstützung für MySQL und MariaDB befindet sich in Vorbereitung. Wenn Ihr Zielsystem nicht in dieser Liste enthalten ist, sprechen Sie uns an. In vielen Fällen lässt sich prüfen, ob eine Erweiterung oder projektspezifische Umsetzung sinnvoll möglich ist.

[ Migration anfragen ]

[ Lizenz & Preise ansehen ]

Warum SQLBase heute zur Bremse werden kann

SQLBase war und ist in vielen Anwendungen eine zuverlässige Datenbankbasis. Viele Systeme laufen damit seit Jahren, teilweise seit Jahrzehnten. Genau deshalb sind SQLBase-Installationen oft geschäftskritisch.

Aber stabile Altsysteme haben eine unangenehme Eigenschaft:
Sie funktionieren erstaunlich lange – bis Modernisierung plötzlich nicht mehr optional ist.

Wer heute SQLBase ablösen möchte, tut das meist aus drei Gründen.

1. Technische Modernisierung

Moderne .NET-Architekturen brauchen moderne Datenbankintegration

Viele aktuelle .NET-Anwendungen setzen auf ORM-Technologien wie Entity Framework Core. Dafür braucht es passende Datenbankprovider. Microsoft führt für EF Core zahlreiche Provider auf, unter anderem für SQL Server, PostgreSQL, SQLite, MySQL/MariaDB und Oracle; SQLBase gehört dort nicht zu den üblichen gelisteten Standardprovidern.

Database Providers – learn.microsoft.com

Das bedeutet in der Praxis:

• kein sauberer Standardweg für Entity Framework Core
• mehr Sonderlogik im Datenzugriff
• Abhängigkeit von klassischen Zugriffsschichten wie ODBC oder älteren Datenprovidern
• höherer Aufwand bei Refactoring, Neuentwicklung und Modernisierung
• weniger Anschluss an aktuelle .NET-Entwicklungsmodelle

Kurz gesagt:

SQLBase läuft.
Aber sie passt immer schlechter in moderne .NET-Landschaften.

Und natürlich kann man vieles irgendwie weiterbauen.
Man kann auch mit einem Oldtimer täglich zum Kunden fahren. Die Frage ist nur, ob das eine Mobilitätsstrategie ist.

2. Wirtschaftliche Gründe

Datenbanklizenzen sind kein Nebengeräusch

SQLBase ist in typischen produktiven Einsatzszenarien ein zusätzlicher Kostenblock. Dieser muss bei jeder Installation, jeder Erweiterung und jeder Kundenauslieferung berücksichtigt werden.

Gerade bei kleineren Installationen mit etwa 5 bis 25 Benutzern kann das spürbar ins Gewicht fallen. Die Anwendung selbst mag schlank sein – die Datenbanklizenz macht das Gesamtpaket trotzdem teurer.

Moderne Zielsysteme bieten hier mehr Flexibilität:

• Microsoft SQL Server Express ist eine kostenlose SQL-Server-Edition für kleinere Desktop-, Web- und Serveranwendungen.
  Microsoft® SQL Server® 2022 Express – microsoft.com
  
  
• PostgreSQL steht unter einer liberalen Open-Source-Lizenz und kann ohne Lizenzgebühren genutzt, kopiert, verändert und verteilt werden.
  PostgreSQL License – postgresql.org
  
  
• MySQL und MariaDB sind als zusätzliche Zielsysteme vorgesehen und erweitern die Auswahl künftig nochmals deutlich.

Damit wird die Datenbank nicht mehr automatisch zum Kostentreiber.

Eine Migration kann sich deshalb bereits dadurch rechnen, dass künftig keine oder deutlich geringere Datenbanklizenzkosten mehr anfallen.

3. Strategische Freiheit

Mehr Plattform. Mehr Werkzeuge. Mehr Auswahl.

Eine Migration von SQLBase auf SQL Server oder PostgreSQL ist nicht nur ein technischer Austausch der Datenbank.

Sie öffnet den Weg in ein größeres Ökosystem:

• bessere Integration in moderne Anwendungen
• breitere Unterstützung durch Entwicklungswerkzeuge
• mehr Know-how am Markt
• moderne Administrations- und Monitoring-Werkzeuge
• bessere Optionen für Backup, Betrieb und Skalierung
• einfachere Einbindung in Cloud-, Container- und DevOps-Szenarien
• geringere Abhängigkeit von einer alternden Spezialtechnologie
• künftig zusätzliche Zielplattformen durch MySQL und MariaDB

Das reduziert langfristig Projektrisiken.

Und Risiken sind in der IT bekanntlich selten dann teuer, wenn man sie erkennt — teuer werden sie, wenn man sie jahrelang ignoriert hat.

Was sqlbase2db macht

sqlbase2db ist ein professionelles Kommandozeilenwerkzeug zur automatisierten Migration von Gupta-SQLBase-Datenbanken.

Das Programm liest die SQLBase-Quelldatenbank aus und erzeugt daraus ausführbare SQL-Skripte für das Zielsystem.

Dabei werden nicht nur Daten exportiert, sondern auch Datenbankstruktur, Views und Indizes übernommen.

Automatisierter Schema-Export

sqlbase2db analysiert die Tabellenstruktur der SQLBase-Datenbank und überträgt sie in die Syntax des Zielsystems.

Dabei werden unter anderem verarbeitet:

• Tabellen
• Spalten
• Datentypen
• Längen und Genauigkeiten
• NULL-/NOT-NULL-Definitionen
• Views
• technische Besonderheiten der Zielplattform

Das Ziel ist eine lauffähige Struktur auf SQL Server oder PostgreSQL – ohne manuelles Nachbauen der Datenbank.

Views werden übernommen

Vorhandene SQLBase-Views werden beim Schema-Export berücksichtigt und in das Zielsystem übertragen, soweit dies technisch eindeutig abbildbar ist.

Bei einfachen Views ist dies in der Regel unproblematisch. Bei komplexeren Views kann jedoch SQLBase-spezifische Syntax enthalten sein, zum Beispiel proprietäre Funktionen, besondere String-Verkettungen oder datenbankspezifische Ausdrücke.

Solche Views sollten nach der Migration fachlich und technisch geprüft werden. sqlbase2db nimmt die strukturelle Übertragung vor – ersetzt aber keine fachliche Bewertung datenbankspezifischer Anwendungslogik.

Das ist keine Schwäche, sondern die Realität bei SQL-Dialekten. Wer anderes verspricht, hat entweder ein sehr kleines Beispiel oder sehr viel Optimismus.

Vollständiger Datenexport

Nach dem Schema-Export werden die Datenbestände der SQLBase-Tabellen exportiert.

sqlbase2db erzeugt ausführbare INSERT-Skripte und berücksichtigt dabei typische Stolperstellen:

• Sonderzeichen
• Datums- und Zeitwerte
• NULL-Werte
• numerische Formate
• Binärdaten
• große Datenmengen
• SQLBase-spezifische Eigenheiten

Der Export erfolgt reproduzierbar und nachvollziehbar.

Umgang mit SQLBase ROWID

Gupta SQLBase arbeitet intern mit einer ROWID, die in bestehenden Anwendungen häufig eine praktische Rolle spielt – manchmal ausdrücklich, manchmal eher historisch gewachsen.

Bei einer Migration auf SQL Server, PostgreSQL oder andere moderne Zielsysteme kann diese ROWID nicht einfach 1:1 als identisches internes Datenbankkonzept vorausgesetzt werden. Andere Datenbanken haben andere Mechanismen, andere Garantien und andere Vorstellungen davon, was eine interne Zeilenadresse sein soll.

sqlbase2db berücksichtigt dieses Problem und stellt eine eigene Lösung bereit:

• SQLBase-ROWID-Werte können beim Export erkannt und berücksichtigt werden.
• Falls erforderlich, kann eine technische Ersatzspalte im Zielsystem erzeugt werden.
• Bestehende Bezüge auf ROWID lassen sich dadurch nachvollziehbarer in die Zielwelt überführen.
• Die Zielstruktur bleibt transparent und prüfbar.

Damit wird aus einer SQLBase-internen Eigenheit kein stiller Migrationssprengsatz.

Wichtig bleibt dennoch: Wenn eine Anwendung fachlich stark auf SQLBase-ROWID-Logik aufbaut, sollte dieser Bereich bei der Anwendungsumstellung bewusst geprüft werden. sqlbase2db nimmt die technische Hürde – die fachliche Bedeutung kennt im Zweifel nur die Anwendung selbst.

Index- und Constraint-Export

Nach Struktur und Daten erzeugt sqlbase2db die Skripte für Indizes und Unique-Constraints.

Das ist bewusst getrennt, weil es in Migrationsprojekten meist sinnvoller ist, zuerst die Struktur anzulegen, dann die Daten einzuspielen und anschließend die Indizes aufzubauen.

Das Ergebnis ist ein sauberer, kontrollierbarer Ablauf.

Was bewusst nicht automatisch migriert wird

sqlbase2db konzentriert sich auf die zuverlässige Migration von:

• Tabellenstrukturen
• Views
• Daten
• Indizes
• Unique-Constraints

Trigger und Stored Procedures werden nicht automatisch migriert.

Falls in der SQLBase-Datenbank Trigger oder Stored Procedures vorhanden sind, müssen diese im Zielsystem manuell geprüft und dort neu eingerichtet werden.

Der Grund ist einfach: Trigger und Stored Procedures enthalten häufig datenbankspezifische Logik, Syntax und Seiteneffekte. Eine automatische 1:1-Übersetzung wäre in vielen Fällen unseriös – und unseriös können andere besser.

Statt stillschweigend fragwürdige Zielskripte zu erzeugen, bleibt sqlbase2db hier bewusst transparent.

Klare Ausgabedateien

sqlbase2db erzeugt getrennte Dateien für die einzelnen Migrationsschritte.

Beispiel für SQL Server:

Datei	Beschreibung
mssql_meinedb_01_schema.sql	Tabellenstruktur und Views anlegen
mssql_meinedb_02_data.sql	Daten einspielen
mssql_meinedb_03_indexes.sql	Indizes und Constraints erzeugen
mssql_readme.txt	Schritt-für-Schritt-Anleitung

Analog werden entsprechende Dateien für PostgreSQL erzeugt.

Das macht die Migration transparent, prüfbar und wiederholbar.

Typischer Ablauf

Eine Migration mit sqlbase2db folgt einem klaren Ablauf:

1. Verbindung zur SQLBase-Datenbank herstellen
   sqlbase2db greift über den installierten SQLBase Client auf die Quelldatenbank zu.
2. Zielsystem auswählen
   Aktuell Microsoft SQL Server oder PostgreSQL. MySQL und MariaDB sind als weitere Zielsysteme vorgesehen.
3. Export starten
   Das Tool liest Struktur, Views, Daten und Indizes aus.
4. SQL-Skripte prüfen
   Die erzeugten Dateien können versioniert, geprüft und dokumentiert werden.
5. Skripte auf dem Zielsystem ausführen
   Schema, Daten und Indizes werden in definierter Reihenfolge eingespielt.
6. Trigger und Stored Procedures prüfen
   Falls vorhanden, werden diese fachlich und technisch bewertet und im Zielsystem manuell eingerichtet.
7. Anwendung umstellen und testen
   Die migrierte Datenbank steht anschließend für Modernisierung, Portierung oder Weiterbetrieb zur Verfügung.

So sieht eine Migration mit sqlbase2db aus

sqlbase2db ist ein Kommandozeilenwerkzeug.

Die Migration wird über einen klaren Aufruf gestartet und erzeugt anschließend getrennte SQL-Dateien für Struktur, Daten und Indizes.

Die folgenden Beispiele sind gekürzt und dienen der Veranschaulichung. In realen Migrationen erzeugt sqlbase2db vollständige Skripte für alle unterstützten Tabellen, Views, Daten und Indizes der SQLBase-Datenbank.

Beispiel: Start über die Kommandozeile

sqlbase2db.exe ^
  --source "server=SQLBASESERVER;database=MEINEDB;user=SYSADM;password=***" ^
  --target postgresql ^
  --output "C:\migration\meinedb" ^
  --license "C:\licenses\sqlbase2db.lic"

Oder für Microsoft SQL Server:

sqlbase2db.exe ^
  --source "server=SQLBASESERVER;database=MEINEDB;user=SYSADM;password=***" ^
  --target mssql ^
  --output "C:\migration\meinedb" ^
  --license "C:\licenses\sqlbase2db.lic"Die konkrete Syntax kann je nach Version abweichen.

Das Prinzip bleibt: Quelle angeben, Zielsystem wählen, Ausgabeordner festlegen, Migration starten.

Beispiel: Konsolenausgabe

sqlbase2db 1.0.0
Copyright (c) 2026 isential gmbh

License.................. valid
Licensed to.............. Musterfirma GmbH
Source database.......... MEINEDB
Target system............ PostgreSQL
Output directory......... C:\migration\meinedb

Connecting to SQLBase.... OK
Reading schema........... OK
Tables found............. 184
Views found.............. 27
Indexes found............ 312
Unique constraints....... 48
Triggers found........... 6
Stored procedures found.. 12

Checking ROWID usage..... detected
ROWID strategy........... create technical replacement column

Exporting schema......... OK
Exporting views.......... OK
Exporting data........... OK
Exporting indexes........ OK
Writing readme........... OK

Created files:
  pgsql_meinedb_01_schema.sql
  pgsql_meinedb_02_data.sql
  pgsql_meinedb_03_indexes.sql
  pgsql_readme.txt

Note:
  Triggers and stored procedures were detected.
  These objects are not migrated automatically and must be reviewed manually.
  Migration export completed successfully. 

Diese Ausgabe zeigt bewusst nicht nur den Erfolgsfall, sondern auch die relevanten Hinweise:

• Views werden erkannt
• ROWID wird behandelt
• Trigger und Stored Procedures werden transparent gemeldet

Beispiel: Erzeugte Dateien

C:\migration\meinedb\

  pgsql_meinedb_01_schema.sql   Tabellenstruktur und Views anlegen
  pgsql_meinedb_02_data.sql     Daten einspielen
  pgsql_meinedb_03_indexes.sql  Indizes und Constraints erzeugen 
  pgsql_readme.txt              Schritt-für-Schritt-Anleitung 

Für Microsoft SQL Server werden entsprechende mssql_...-Dateien erzeugt.

Beispiel: Auszug aus schema.sql

-- Generated by sqlbase2db
-- Licensed to:     Musterfirma GmbH
-- License ID:      SB2DB-2026-04-ABCD1234
-- Source database: MEINEDB
-- Target system:   PostgreSQL
-- Generated at:    2026-05-07 10:30:00

CREATE TABLE kunden (
  kunden_nr      INTEGER NOT NULL,
  name           VARCHAR(80) NOT NULL,
  ort            VARCHAR(80),
  angelegt_am    TIMESTAMP,
  gesperrt       INTEGER DEFAULT 0,
  sqlbase_rowid  BIGINT
); 

Der Dateikopf macht nachvollziehbar, mit welcher Lizenz, für welche Quelle und für welches Zielsystem das Skript erzeugt wurde.

Die technische Spalte sqlbase_rowid ist ein Beispiel dafür, wie SQLBase-ROWID-Informationen bei Bedarf transparent in die Zielstruktur übernommen werden können.

Beispiel: Auszug aus einer View

CREATE VIEW kunden_aktiv AS
SELECT
  kunden_nr,
  name,
  ort
FROM kunden
WHERE gesperrt = 0; 

Views werden also nicht verschwiegen, sondern als eigener Bestandteil der Strukturmigration sichtbar gemacht.

Hinweis:
Bei komplexen SQLBase-spezifischen View-Definitionen kann eine fachliche Prüfung nach der Migration sinnvoll sein.

Beispiel: Auszug aus data.sql

BEGIN;

INSERT INTO kunden
  (kunden_nr, name, ort, angelegt_am, gesperrt, sqlbase_rowid)
VALUES
  (10001, 'Muster GmbH', 'Trossingen', '2024-03-18 09:15:00', 0, 123456789);

INSERT INTO kunden
  (kunden_nr, name, ort, angelegt_am, gesperrt, sqlbase_rowid)
VALUES
  (10002, 'Beispiel AG', 'Villingen-Schwenningen', '2024-04-02 14:20:00', 0, 123456790);

COMMIT;

Das Beispiel zeigt:

• lesbare INSERT-Struktur
• transaktionssichere Ausgabe
• nachvollziehbare Datenübernahme
• ROWID-Behandlung, wenn benötigt

Beispiel: Auszug aus indexes.sql

CREATE UNIQUE INDEX ux_kunden_kunden_nr
ON kunden (kunden_nr);

CREATE INDEX ix_kunden_name
ON kunden (name); 

Indizes und Unique-Constraints werden bewusst separat erzeugt, nachdem Struktur und Daten eingespielt wurden.

Das ist in Migrationsprojekten meist sinnvoller, schneller und besser kontrollierbar.

Beispiel: Auszug aus readme.txt

sqlbase2db Migration Readme
===========================

Source database:
  MEINEDB

Target system:
  PostgreSQL

Generated files:
  pgsql_meinedb_01_schema.sql
  pgsql_meinedb_02_data.sql
  pgsql_meinedb_03_indexes.sql

Execution order:
  1. pgsql_meinedb_01_schema.sql
  2. pgsql_meinedb_02_data.sql
  3. pgsql_meinedb_03_indexes.sql

Important notes:
  - Review generated views if they contain SQLBase-specific syntax.
  - Triggers and stored procedures are not migrated automatically.
  - If your application uses SQLBase ROWID semantics, review the generated ROWID mapping.

Die Readme dokumentiert die Reihenfolge und weist auf Punkte hin, die im Zielsystem bewusst geprüft werden sollten.

Lokal statt Cloud

sqlbase2db läuft lokal in Ihrer Umgebung.

Ihre produktiven Datenbanken werden nicht zu uns hochgeladen.
Es gibt keine Cloud-Migration, keinen Upload Ihrer SQLBase-Daten und keine externe Verarbeitung Ihrer Datenbestände.

Die Online-Kommunikation dient ausschließlich der Lizenzprüfung und Aktivierung.

Das ist besonders wichtig für:

• produktive Unternehmensdaten
• Kundendatenbanken
• sensible Branchen
• interne Compliance-Vorgaben
• Dienstleister mit Mandantendaten

Kurz gesagt:
Ihre Daten bleiben dort, wo sie hingehören: bei Ihnen.

Für wen ist sqlbase2db gedacht?

sqlbase2db richtet sich an Unternehmen und Dienstleister, die SQLBase nicht länger als technische oder wirtschaftliche Bremse mitführen möchten.

Typische Anwender sind:

• Unternehmen mit bestehenden SQLBase-Anwendungen
• ERP-Hersteller und Softwarehäuser mit SQLBase-Altbeständen
• IT-Dienstleister mit SQLBase-Migrationsprojekten
• Entwicklerteams, die bestehende Anwendungen modernisieren
• Betreiber von Branchenlösungen mit vielen Kundendatenbanken
• Organisationen, die SQLBase-Lizenzkosten reduzieren möchten
• Anwender, die künftig SQL Server, PostgreSQL, MySQL oder MariaDB als strategische Datenbankplattform nutzen möchten

sqlbase2db ist für ernsthafte Ablösungs- und Modernisierungsprojekte entwickelt.

Für einzelne Ad-hoc-Exporte, experimentelle Spieltests oder „wir schauen mal, ob wir vielleicht irgendwann eventuell migrieren“ ist das Werkzeug bewusst nicht optimiert.

Das spart Zeit. Auf beiden Seiten.

Aus SQLBase-Praxis entstanden

Hinter sqlbase2db steht die isential gmbh mit rund 36 Jahren Erfahrung im praktischen Einsatz von Gupta SQLBase.

Wir kennen SQLBase nicht aus Datenblättern.
Wir kennen SQLBase aus echten Anwendungen, echten Kundeninstallationen und echten Migrationsproblemen.

Diese Erfahrung ist wichtig, weil SQLBase-Migrationen selten an den offensichtlichen Dingen scheitern.

Nicht die Tabelle KUNDEN ist das Problem.
Das Problem sind die Details:

• Datentypen
• Sonderzeichen
• alte Datenbestände
• historisch gewachsene Strukturen
• Views
• Indizes
• ROWID
• proprietäre Eigenheiten
• große Tabellen
• produktive Daten mit sehr langer Vergangenheit
• Trigger und Stored Procedures, die bewusst separat betrachtet werden müssen

sqlbase2db ist deshalb kein Laborprodukt, sondern ein Werkzeug aus der Praxis.

Oder etwas kürzer:
Wir verkaufen keine Magie — wir nehmen nur die Fleißarbeit aus einem Projekt, bei dem Fleißarbeit erstaunlich teuer werden kann.

Vorteile gegenüber manueller Migration

Eine manuelle SQLBase-Migration ist möglich.
So wie man auch Fliesen mit dem Taschenmesser entfernen kann.

Die Frage ist nur, ob man das möchte.

sqlbase2db reduziert typische Risiken manueller Migrationen:

Weniger manuelle Strukturarbeit

Tabellen, Spalten, Views und Datentypen müssen nicht einzeln übertragen werden.

Reproduzierbare Ergebnisse

Die Migration lässt sich wiederholen, prüfen und dokumentieren.

Klare Trennung der Schritte

Schema, Daten und Indizes werden getrennt ausgegeben.

Weniger Fehlerquellen

Sonderzeichen, Datumswerte, Binärdaten, NULL-Werte und SQLBase-spezifische Besonderheiten werden systematisch behandelt.

Transparenter Umgang mit Grenzen

Trigger und Stored Procedures werden nicht automatisch übersetzt, sondern bewusst als manuell zu prüfende Datenbanklogik behandelt.

Bessere Planbarkeit

Testmigrationen und Produktivläufe können mit denselben Mechanismen durchgeführt werden.

Geringerer Projektaufwand

Die eigentliche Migration wird nicht zum wochenlangen Handarbeitsprojekt.

Lizenzierung & Preise

Wir setzen auf klare Preise statt Preisdschungel.

sqlbase2db ist ein professionelles Werkzeug für produktive Migrationsprojekte. Das Lizenzmodell ist bewusst einfach gehalten:

• unbefristete Nutzungslizenz
• Abrechnung nach Migrationseinheiten
• mehrere Migrationen im Grundpreis enthalten
• lokale Nutzung
• regelmäßige Onlineprüfung zur Lizenzbindung
• keine Cloud-Übertragung Ihrer Daten

Was ist eine Migrationseinheit?

Eine Migrationseinheit bezeichnet die vollständige Migration einer technisch eigenständigen SQLBase-Datenbankinstanz – bestehend aus Struktur, Views, Daten und Indizes – in eine Zieldatenbank.

Wichtig:

• Der Datenbankname allein ist nicht entscheidend.
• Gleiche Struktur bedeutet nicht gleiche Datenbank.
• Mehrere Kundendatenbanken mit gleicher Struktur sind jeweils eigene Migrationseinheiten.
• Wiederholte Testläufe derselben Datenbank sollen nicht künstlich mehrfach zählen.

Die Lizenzierung orientiert sich also am tatsächlichen Migrationsnutzen, nicht an willkürlichen Dateinamen.

Grundlizenz

4.500 € einmalig

Enthalten sind:

• unbefristete Nutzungslizenz
• 3 vollständige Migrationseinheiten
• Zielsysteme: Microsoft SQL Server und PostgreSQL
• MySQL und MariaDB nach Verfügbarkeit der entsprechenden Module
• lokale Ausführung
• keine Cloud-Datenübertragung
• vollständige Skript- und Dokumentationsausgabe
• Lizenzhinweise in den erzeugten Ausgabedateien
• regelmäßige Onlineprüfung zur Sicherstellung der Lizenzbindung

Die Grundlizenz ist für typische Migrationsprojekte ausgelegt und deckt in vielen Fällen Testläufe, Generalprobe und Produktivumstellung ab.

Zusätzliche Migrationen

Für Projekte mit mehreren Datenbankinstanzen können zusätzliche Migrationseinheiten nachlizenziert werden.

Anzahl	Beschreibung	Preis
1	zusätzliche Migration	1.200 €
5	zusätzliche Migrationen	5.000 €
10	zusätzliche Migrationen	9.000 €

Zusatzmigrationen lassen sich jederzeit ergänzen und nach Aktivierung nutzen.

Projekt- und Volumenlizenzen

Für größere Ablösungsprojekte, IT-Dienstleister oder Umgebungen mit vielen Mandanten bieten wir Projekt- und Volumenlizenzen an.

Diese werden klar umrissen und projektbezogen vereinbart, zum Beispiel für:

• definierte Kundenprojekte
• größere Mandantenlandschaften
• Dienstleister mit mehreren SQLBase-Kunden
• Softwarehersteller mit vielen Installationen
• Zielsysteme außerhalb des Standardumfangs

Sprechen Sie uns an, wenn Ihr Szenario außerhalb der Standardmodelle liegt.

Wir sind pragmatisch — nur eben nicht beliebig.

Technische Voraussetzungen

sqlbase2db läuft aktuell unter Windows, da der Zugriff auf Gupta SQLBase in typischen Bestandsumgebungen über den installierten SQLBase Client erfolgt.

Die erzeugten SQL-Skripte sind davon unabhängig und können anschließend auf dem jeweiligen Zielsystem ausgeführt, versioniert oder in bestehende Deployment-Prozesse übernommen werden.

Für den Einsatz von sqlbase2db benötigen Sie:

• Windows
• installierten Gupta SQLBase Client
• Netzwerkzugang zur SQLBase-Quelldatenbank
• .NET Runtime
• Zugriff auf das Zielsystem Microsoft SQL Server oder PostgreSQL

Weitere Zielsysteme:

• MySQL in Vorbereitung
• MariaDB in Vorbereitung

Falls Sie eine andere Zieldatenbank benötigen, sprechen Sie uns an. Wir prüfen gerne, ob eine Unterstützung technisch und wirtschaftlich sinnvoll umgesetzt werden kann.

Häufige Fragen

Werden unsere Daten an isential übertragen?

Nein.

sqlbase2db läuft lokal in Ihrer Umgebung. Ihre SQLBase-Daten werden nicht zu isential hochgeladen und nicht extern verarbeitet.

Die Onlineverbindung dient ausschließlich der Lizenzprüfung und Aktivierung.

Ist die Lizenz zeitlich begrenzt?

Nein.

Die Nutzungslizenz ist unbefristet. Die regelmäßige Onlineprüfung dient nicht als Abo-Modell, sondern verhindert missbräuchliche Mehrfachnutzung und stellt sicher, dass die Lizenz an die berechtigte Instanz gebunden bleibt.

Warum sind mehrere Migrationen in der Grundlizenz enthalten?

Weil echte Migrationsprojekte selten aus genau einem Knopfdruck bestehen.

In der Praxis gibt es Testläufe, Prüfungen, Anpassungen und eine Produktivumstellung. Die Grundlizenz ist so ausgelegt, dass typische Projekte nicht bei jedem sinnvollen Testlauf in eine Lizenzdiskussion geraten.

Warum wird nach Datenbankinstanzen lizenziert?

Weil der Nutzen pro migrierter Datenbank entsteht.

Eine SQLBase-Datenbank mit produktiven Kundendaten ist eine eigene Migrationseinheit – unabhängig davon, ob sie denselben Namen oder dieselbe Struktur wie eine andere Datenbank hat.

Das ist einfach, nachvollziehbar und fair.

Gibt es eine kostenlose Testversion?

Nein, derzeit ist keine klassische Testversion vorgesehen.

sqlbase2db ist kein Massen-Download für experimentelle Tests, sondern ein Werkzeug für produktive Migrationsprojekte. Eine künstlich begrenzte Testversion würde bei komplexen SQLBase-Beständen oft mehr Fragen erzeugen als beantworten.

Stattdessen zeigen wir auf dieser Seite beispielhaft, wie Aufruf, Ausgabe und erzeugte SQL-Skripte aussehen.

Wenn Sie ein konkretes Migrationsszenario haben, sprechen Sie uns an. Wir klären dann pragmatisch, wie sich Ihre Datenbankstruktur, Zielplattform und Besonderheiten vorab einschätzen lassen.

Unterstützt sqlbase2db auch MySQL oder MariaDB?

Aktuell unterstützt sqlbase2db Microsoft SQL Server und PostgreSQL.

Die Unterstützung für MySQL und MariaDB ist fest vorgesehen und befindet sich in Vorbereitung.

Wenn Ihr Projekt MySQL oder MariaDB als Zielsystem benötigt, sprechen Sie uns an. Je nach Projektstand kann eine frühe Abstimmung sinnvoll sein.

Was ist mit anderen Zieldatenbanken?

Wenn Sie eine andere Zieldatenbank benötigen, sprechen Sie uns an.

sqlbase2db ist so konzipiert, dass weitere Zielsysteme grundsätzlich ergänzt werden können. Ob dies im konkreten Fall sinnvoll ist, hängt vom gewünschten Zielsystem, vom Umfang der SQLBase-Datenbank und vom Projektkontext ab.

Werden Views migriert?

Ja.

Vorhandene Views werden beim Schema-Export berücksichtigt und in das Zielsystem übertragen, soweit dies technisch eindeutig möglich ist.

Bei sehr spezifischer SQLBase-Syntax kann eine fachliche Prüfung einzelner Views sinnvoll sein.

Was passiert mit SQLBase ROWID?

SQLBase-ROWID ist eine Besonderheit, die bei Migrationen bewusst behandelt werden muss.

sqlbase2db berücksichtigt ROWID-abhängige Szenarien und kann bei Bedarf eine transparente technische Ersatzlösung im Zielsystem erzeugen.

Wenn Ihre Anwendung stark auf ROWID basiert, sollte dieser Bereich im Rahmen der Anwendungsumstellung zusätzlich geprüft werden.

Werden Trigger und Stored Procedures migriert?

Nein.

Trigger und Stored Procedures enthalten häufig echte Anwendungslogik. Diese Logik ist meist eng an den SQL-Dialekt, das Transaktionsverhalten und die Funktionen der jeweiligen Datenbank gebunden.

Eine automatische Übersetzung in ein anderes Zielsystem wäre in vielen Fällen nicht zuverlässig genug. Deshalb migriert sqlbase2db Trigger und Stored Procedures bewusst nicht automatisch.

Vorhandene Trigger und Stored Procedures werden erkannt und ausgewiesen, müssen aber im Zielsystem fachlich geprüft und manuell eingerichtet werden.

Muss die Zielstruktur manuell nachbearbeitet werden?

Ziel von sqlbase2db ist es, die SQLBase-Struktur automatisiert in lauffähige SQL-Skripte für das Zielsystem zu übertragen.

Je nach Anwendung kann danach dennoch eine fachliche oder technische Optimierung sinnvoll sein – etwa im Rahmen einer Modernisierung, Performanceanpassung oder Anwendungsportierung.

Die manuelle Grundübertragung der Datenbankstruktur soll sqlbase2db jedoch gerade vermeiden.

Unterstützt sqlbase2db inkrementelle Migrationen oder Delta-Exporte?

sqlbase2db ist aktuell auf vollständige Migrationsläufe ausgelegt.

Das Werkzeug erzeugt vollständige Skripte für Struktur, Views, Daten und Indizes der SQLBase-Quelldatenbank. Für viele Ablösungsprojekte ist genau dieser reproduzierbare Komplettlauf der sauberste und am besten prüfbare Weg.

Inkrementelle Migrationen oder Delta-Exporte – also nur seit einem bestimmten Zeitpunkt geänderte Daten – sind aktuell nicht Bestandteil des Standardumfangs.

Wenn Ihr Projekt besonders kurze Umschaltzeiten erfordert, sprechen Sie uns an. In solchen Fällen sollte die Migrationsstrategie individuell betrachtet werden, etwa über Testmigrationen, geplante Umschaltfenster oder projektspezifische Verfahren.

Bereit für den Umstieg?

Niemand kauft sqlbase2db, weil er ein weiteres Kommandozeilenwerkzeug in der Sammlung braucht.

Gekauft wird die Möglichkeit, SQLBase sauber, nachvollziehbar und mit deutlich weniger Handarbeit hinter sich zu lassen.

Sie planen eine SQLBase-Migration?

[ Migration anfragen ]

[ Lizenz & Preise ansehen ]

sqlbase2db ist ein Produkt der isential gmbh.
Copyright © 2026 isential gmbh. Alle Rechte vorbehalten.