Automated migration of Gupta SQLBase databases to Microsoft SQL Server, PostgreSQL, MySQL and MariaDB – including structure, views, data and indexes. Local. Reproducible. Without manual schema work.

Gupta SQLBase has been running reliably in many companies for decades – that is not the problem.

The problem begins where modern applications, current .NET architectures, flexible database platforms and sensible licensing models are required.

sqlbase2db helps migrate existing SQLBase databases cleanly to modern target systems – without weeks of manual labour on tables, data types, views, data exports and index definitions.

Currently supported target systems:

• Microsoft SQL Server
• PostgreSQL

Additional target systems are firmly planned:

• MySQL
• MariaDB

Support for MySQL and MariaDB is currently in preparation. If your target system is not listed here, please contact us. In many cases, we can evaluate whether an extension or project-specific implementation makes sense.

[ Request migration ]

[ View license & pricing ]

Why SQLBase can become a bottleneck today

SQLBase has been, and still is, a reliable database foundation for many applications. Many systems have been running on it for years, sometimes for decades. That is exactly why SQLBase installations are often business-critical.

But stable legacy systems have one unpleasant habit:
They keep working for a surprisingly long time – until modernization suddenly stops being optional.

Companies usually want to replace SQLBase for three reasons.

1. Technical modernization

Modern .NET architectures need modern database integration

Many current .NET applications rely on ORM technologies such as Entity Framework Core. This requires suitable database providers. Microsoft lists numerous providers for EF Core, including SQL Server, PostgreSQL, SQLite, MySQL/MariaDB and Oracle; SQLBase is not among the commonly listed standard providers.

Database Providers – learn.microsoft.com

In practice, this means:

• no clean standard path for Entity Framework Core
• more custom data access logic
• dependency on classic access layers such as ODBC or older data providers
• higher effort for refactoring, new development and modernization
• less alignment with current .NET development models

In short:

SQLBase runs.
But it fits less and less comfortably into modern .NET landscapes.

And of course, many things can somehow be kept alive.
You can also drive a vintage car to customers every day. The only question is whether that qualifies as a mobility strategy.

2. Economic reasons

Database licenses are not background noise

In typical production scenarios, SQLBase is an additional cost factor. It must be considered with every installation, every extension and every customer rollout.

This becomes particularly noticeable in smaller installations with around 5 to 25 users. The application itself may be lean – but the database license still makes the overall package more expensive.

Modern target systems offer more flexibility here:

• Microsoft SQL Server Express is a free SQL Server edition for smaller desktop, web and server applications.
  Microsoft® SQL Server® 2022 Express – microsoft.com
  
  
• PostgreSQL is released under a liberal open-source license and can be used, copied, modified and distributed without license fees.
  PostgreSQL License – postgresql.org
  
  
• MySQL and MariaDB are planned as additional target systems and will further expand the available options.

This means the database no longer automatically becomes a cost driver.

In many cases, a migration can already pay for itself simply by avoiding future SQLBase license costs or significantly reducing database licensing expenses.

3. Strategic freedom

More platform. More tools. More choice.

Migrating from SQLBase to SQL Server or PostgreSQL is not just a technical replacement of the database.

It opens the door to a broader ecosystem:

• better integration into modern applications
• broader support by development tools
• more know-how available on the market
• modern administration and monitoring tools
• better options for backup, operation and scaling
• easier integration into cloud, container and DevOps scenarios
• less dependency on an aging specialist technology
• additional future target platforms through MySQL and MariaDB

This reduces project risks in the long term.

And as we all know, risks in IT rarely become expensive when they are recognized — they become expensive when they have been ignored for years.

What sqlbase2db does

sqlbase2db is a professional command-line tool for automated migration of Gupta SQLBase databases.

The program reads the SQLBase source database and generates executable SQL scripts for the target system.

It does not merely export data. It also migrates the database structure, views and indexes.

Automated schema export

sqlbase2db analyzes the table structure of the SQLBase database and translates it into the syntax of the target system.

Among other things, it processes:

• tables
• columns
• data types
• lengths and precision
• NULL / NOT NULL definitions
• views
• technical specifics of the target platform

The goal is a runnable structure on SQL Server or PostgreSQL – without manually rebuilding the database.

Views are migrated

Existing SQLBase views are considered during schema export and transferred to the target system, as far as they can be mapped technically and unambiguously.

For simple views, this is usually straightforward. More complex views may contain SQLBase-specific syntax, for example proprietary functions, special string concatenation or database-specific expressions.

Such views should be reviewed functionally and technically after migration. sqlbase2db performs the structural transfer – but it does not replace a functional assessment of database-specific application logic.

That is not a weakness. It is simply the reality of SQL dialects. Anyone promising otherwise either has a very small example or a very large amount of optimism.

Complete data export

After the schema export, sqlbase2db exports the data from the SQLBase tables.

sqlbase2db generates executable INSERT scripts and handles typical stumbling blocks:

• special characters
• date and time values
• NULL values
• numeric formats
• binary data
• large data volumes
• SQLBase-specific behavior

The export is reproducible and traceable.

Handling SQLBase ROWID

Gupta SQLBase internally works with a ROWID, which often plays a practical role in existing applications – sometimes explicitly, sometimes more historically grown.

When migrating to SQL Server, PostgreSQL or other modern target systems, this ROWID cannot simply be assumed to exist as an identical internal database concept. Other databases have different mechanisms, different guarantees and different ideas about what an internal row address should be.

sqlbase2db takes this issue into account and provides a dedicated solution:

• SQLBase ROWID values can be detected and considered during export.
• If required, a technical replacement column can be created in the target system.
• Existing references to ROWID can be transferred more transparently into the target world.
• The target structure remains transparent and verifiable.

This prevents a SQLBase-internal peculiarity from becoming a quiet migration landmine.

Nevertheless, if an application relies heavily on SQLBase ROWID logic, this area should be deliberately reviewed during application migration. sqlbase2db removes the technical hurdle – but the functional meaning is something only the application itself can know.

Index and constraint export

After structure and data, sqlbase2db generates the scripts for indexes and unique constraints.

This is deliberately separated because, in migration projects, it is usually more sensible to create the structure first, then load the data and finally build the indexes.

The result is a clean, controllable process.

What is deliberately not migrated automatically

sqlbase2db focuses on reliably migrating:

• table structures
• views
• data
• indexes
• unique constraints

Triggers and stored procedures are not migrated automatically.

If triggers or stored procedures exist in the SQLBase database, they must be reviewed manually and recreated in the target system if required.

The reason is simple: triggers and stored procedures often contain database-specific logic, syntax and side effects. An automatic 1:1 translation would be unreliable in many cases – and unreliable is something others can do better.

Instead of silently generating questionable target scripts, sqlbase2db remains deliberately transparent here.

Clear output files

sqlbase2db generates separate files for the individual migration steps.

Example for SQL Server:

File	Description
mssql_mydb_01_schema.sql	Create table structure and views
mssql_mydb_02_data.sql	Load data
mssql_mydb_03_indexes.sql	Create indexes and constraints
mssql_readme.txt	Step-by-step instructions

Corresponding files are generated for PostgreSQL.

This makes the migration transparent, verifiable and repeatable.

Typical process

A migration with sqlbase2db follows a clear process:

1. Connect to the SQLBase database
   sqlbase2db accesses the source database through the installed SQLBase Client.
2. Select the target system
   Currently Microsoft SQL Server or PostgreSQL. MySQL and MariaDB are planned as additional target systems.
3. Start the export
   The tool reads structure, views, data and indexes.
4. Review the SQL scripts
   The generated files can be versioned, reviewed and documented.
5. Execute the scripts on the target system
   Schema, data and indexes are imported in a defined order.
6. Review triggers and stored procedures
   If present, they are functionally and technically evaluated and recreated manually in the target system.
7. Switch and test the application
   The migrated database is then available for modernization, porting or continued operation.

What a migration with sqlbase2db looks like

sqlbase2db is a command-line tool.

The migration is started with a clear command and then generates separate SQL files for structure, data and indexes.

The following examples are shortened for illustration. In real migrations, sqlbase2db generates complete scripts for all supported tables, views, data and indexes of the SQLBase database.

Example: Starting from the command line

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

Or for Microsoft SQL Server:

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

The exact syntax may vary depending on the version.

The principle remains the same: specify the source, choose the target system, set the output directory, start the migration.

Example: Console output

sqlbase2db 1.0.0
Copyright (c) 2026 isential gmbh

License.................. valid
Licensed to.............. Sample Company Ltd.
Source database.......... MYDB
Target system............ PostgreSQL
Output directory......... C:\migration\mydb

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_mydb_01_schema.sql
  pgsql_mydb_02_data.sql
  pgsql_mydb_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.

This output deliberately shows not only the success case, but also the relevant notes:

• views are detected
• ROWID is handled
• triggers and stored procedures are reported transparently

Example: Generated files

C:\migration\mydb\

  pgsql_mydb_01_schema.sql      Create table structure and views
  pgsql_mydb_02_data.sql        Load data
  pgsql_mydb_03_indexes.sql     Create indexes and constraints
  pgsql_readme.txt              Step-by-step instructions

For Microsoft SQL Server, corresponding mssql_... files are generated.

Example: Excerpt from schema.sql

-- Generated by sqlbase2db
-- Licensed to:     Sample Company Ltd.
-- License ID:      SB2DB-2026-04-ABCD1234
-- Source database: MYDB
-- Target system:   PostgreSQL
-- Generated at:    2026-05-07 10:30:00

CREATE TABLE customers (
  customer_no    INTEGER NOT NULL,
  name           VARCHAR(80) NOT NULL,
  city           VARCHAR(80),
  created_at     TIMESTAMP,
  blocked        INTEGER DEFAULT 0,
  sqlbase_rowid  BIGINT
);

The file header makes it clear which license, source and target system were used to generate the script.

The technical column sqlbase_rowid is an example of how SQLBase ROWID information can be transparently transferred into the target structure if required.

Example: Excerpt from a view

CREATE VIEW active_customers AS
SELECT
  customer_no,
  name,
  city
FROM customers
WHERE blocked = 0;

Views are therefore not hidden away, but appear as a visible part of the schema migration.

Note:
For complex SQLBase-specific view definitions, a functional review after migration may be useful.

Example: Excerpt from data.sql

BEGIN;

INSERT INTO customers
  (customer_no, name, city, created_at, blocked, sqlbase_rowid)
VALUES
  (10001, 'Sample Ltd.', 'Trossingen', '2024-03-18 09:15:00', 0, 123456789);

INSERT INTO customers
  (customer_no, name, city, created_at, blocked, sqlbase_rowid)
VALUES
  (10002, 'Example Inc.', 'Villingen-Schwenningen', '2024-04-02 14:20:00', 0, 123456790);

COMMIT;

This example shows:

• readable INSERT structure
• transaction-safe output
• traceable data transfer
• ROWID handling, if required

Example: Excerpt from indexes.sql

CREATE UNIQUE INDEX ux_customers_customer_no
ON customers (customer_no);

CREATE INDEX ix_customers_name
ON customers (name);

Indexes and unique constraints are deliberately generated separately after structure and data have been imported.

In migration projects, this is usually more sensible, faster and easier to control.

Example: Excerpt from readme.txt

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

Source database:
  MYDB

Target system:
  PostgreSQL

Generated files:
  pgsql_mydb_01_schema.sql
  pgsql_mydb_02_data.sql
  pgsql_mydb_03_indexes.sql

Execution order:
  1. pgsql_mydb_01_schema.sql
  2. pgsql_mydb_02_data.sql
  3. pgsql_mydb_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.

The Readme documents the execution order and points out items that should be deliberately reviewed in the target system.

Local instead of cloud

sqlbase2db runs locally in your environment.

Your production databases are not uploaded to us.
There is no cloud migration, no upload of your SQLBase data and no external processing of your data.

Online communication is used exclusively for license verification and activation.

This is particularly important for:

• production company data
• customer databases
• sensitive industries
• internal compliance requirements
• service providers working with client data

In short:
Your data stays where it belongs: with you.

Who is sqlbase2db for?

sqlbase2db is aimed at companies and service providers that no longer want to carry SQLBase as a technical or economic bottleneck.

Typical users include:

• companies with existing SQLBase applications
• ERP vendors and software companies with SQLBase legacy installations
• IT service providers with SQLBase migration projects
• development teams modernizing existing applications
• operators of industry solutions with many customer databases
• organizations wanting to reduce SQLBase license costs
• users planning to use SQL Server, PostgreSQL, MySQL or MariaDB as strategic database platforms

sqlbase2db was developed for serious replacement and modernization projects.

It is deliberately not optimized for individual ad-hoc exports, experimental play tests or “let’s see whether we maybe eventually migrate one day”.

That saves time. On both sides.

Built from SQLBase practice

Behind sqlbase2db is isential gmbh with around 36 years of practical experience using Gupta SQLBase.

We do not know SQLBase from data sheets.
We know SQLBase from real applications, real customer installations and real migration problems.

This experience matters because SQLBase migrations rarely fail because of the obvious things.

The table CUSTOMERS is not the problem.
The problem is in the details:

• data types
• special characters
• old data sets
• historically grown structures
• views
• indexes
• ROWID
• proprietary behavior
• large tables
• production data with a very long history
• triggers and stored procedures that deliberately need to be considered separately

sqlbase2db is therefore not a lab product, but a tool built from practice.

Or, more briefly:
We do not sell magic — we just remove the tedious manual work from a project where tedious manual work can become surprisingly expensive.

Advantages over manual migration

A manual SQLBase migration is possible.
Just as it is possible to remove tiles with a pocket knife.

The only question is whether you really want to.

sqlbase2db reduces typical risks of manual migrations:

Less manual schema work

Tables, columns, views and data types do not have to be transferred one by one.

Reproducible results

The migration can be repeated, reviewed and documented.

Clear separation of steps

Schema, data and indexes are output separately.

Fewer sources of error

Special characters, date values, binary data, NULL values and SQLBase-specific details are handled systematically.

Transparent handling of limits

Triggers and stored procedures are not translated automatically, but deliberately treated as database logic requiring manual review.

Better planning

Test migrations and production runs can be carried out using the same mechanisms.

Reduced project effort

The actual migration does not become a weeks-long manual labour project.

Licensing & pricing

We prefer clear pricing over pricing fog.

sqlbase2db is a professional tool for production migration projects. The licensing model is deliberately simple:

• perpetual usage license
• billing by migration units
• multiple migrations included in the basic license
• local usage
• regular online verification for license binding
• no cloud transfer of your data

What is a migration unit?

A migration unit is the complete migration of one technically independent SQLBase database instance – consisting of structure, views, data and indexes – into a target database.

Important:

• The database name alone is not decisive.
• Same structure does not mean same database.
• Multiple customer databases with the same structure are separate migration units.
• Repeated test runs of the same database should not be artificially counted multiple times.

Licensing is therefore based on the actual migration value, not on arbitrary file names.

Basic license

€4,500 one-time fee

Included:

• perpetual usage license
• 3 complete migration units
• target systems: Microsoft SQL Server and PostgreSQL
• MySQL and MariaDB after availability of the corresponding modules
• local execution
• no cloud data transfer
• complete script and documentation output
• license information in the generated output files
• regular online verification to ensure license binding

The basic license is designed for typical migration projects and, in many cases, covers test runs, dress rehearsal and production migration.

Additional migrations

For projects with multiple database instances, additional migration units can be licensed later.

Quantity	Description	Price
1	additional migration	€1,200
5	additional migrations	€5,000
10	additional migrations	€9,000

Additional migrations can be added at any time and used after activation.

Project and volume licenses

For larger replacement projects, IT service providers or environments with many tenants, we offer project and volume licenses.

These are clearly defined and agreed on a project basis, for example for:

• defined customer projects
• larger tenant landscapes
• service providers with multiple SQLBase customers
• software vendors with many installations
• target systems outside the standard scope

Contact us if your scenario does not fit the standard models.

We are pragmatic — just not arbitrary.

Technical requirements

sqlbase2db currently runs on Windows because access to Gupta SQLBase in typical existing environments is performed through the installed SQLBase Client.

The generated SQL scripts are independent of this and can subsequently be executed on the respective target system, versioned or integrated into existing deployment processes.

To use sqlbase2db, you need:

• Windows
• installed Gupta SQLBase Client
• network access to the SQLBase source database
• .NET Runtime
• access to the target system Microsoft SQL Server or PostgreSQL

Additional target systems:

• MySQL in preparation
• MariaDB in preparation

If you require another target database, please contact us. We will gladly evaluate whether support can be implemented in a technically and economically sensible way.

Frequently asked questions

Will our data be transferred to isential?

No.

sqlbase2db runs locally in your environment. Your SQLBase data is not uploaded to isential and is not processed externally.

The online connection is used exclusively for license verification and activation.

Is the license time-limited?

No.

The usage license is perpetual. Regular online verification is not a subscription model; it prevents abusive multiple use and ensures that the license remains bound to the authorized instance.

Why are multiple migrations included in the basic license?

Because real migration projects rarely consist of exactly one button press.

In practice, there are test runs, reviews, adjustments and a production migration. The basic license is designed so that typical projects do not run into a licensing discussion with every sensible test run.

Why is licensing based on database instances?

Because the value is created per migrated database.

A SQLBase database with production customer data is its own migration unit – regardless of whether it has the same name or the same structure as another database.

That is simple, traceable and fair.

Is there a free trial version?

No, a classic trial version is currently not planned.

sqlbase2db is not a mass download for experimental testing, but a tool for production migration projects. An artificially limited trial version would often create more questions than answers with complex SQLBase databases.

Instead, this page shows examples of the command line, console output and generated SQL scripts.

If you have a concrete migration scenario, please contact us. We will pragmatically clarify how your database structure, target platform and specific requirements can be assessed in advance.

Does sqlbase2db also support MySQL or MariaDB?

sqlbase2db currently supports Microsoft SQL Server and PostgreSQL.

Support for MySQL and MariaDB is firmly planned and currently in preparation.

If your project requires MySQL or MariaDB as the target system, please contact us. Depending on the project status, early coordination may be useful.

What about other target databases?

If you need another target database, please contact us.

sqlbase2db is designed so that additional target systems can generally be added. Whether this makes sense in a specific case depends on the desired target system, the scope of the SQLBase database and the project context.

Are views migrated?

Yes.

Existing views are considered during schema export and transferred to the target system where technically possible.

For very specific SQLBase syntax, a functional review of individual views may be useful.

What happens to SQLBase ROWID?

SQLBase ROWID is a special feature that must be deliberately handled during migrations.

sqlbase2db takes ROWID-dependent scenarios into account and can create a transparent technical replacement in the target system if required.

If your application relies heavily on ROWID, this area should also be reviewed during application migration.

Are triggers and stored procedures migrated?

No.

Triggers and stored procedures often contain real application logic. This logic is usually closely tied to the SQL dialect, transaction behavior and functions of the respective database.

An automatic translation into another target system would often not be reliable enough. Therefore, sqlbase2db deliberately does not migrate triggers and stored procedures automatically.

Existing triggers and stored procedures are detected and reported, but must be reviewed functionally and recreated manually in the target system.

Does the target structure have to be manually reworked?

The goal of sqlbase2db is to automatically transfer the SQLBase structure into runnable SQL scripts for the target system.

Depending on the application, functional or technical optimization may still be useful afterwards – for example during modernization, performance tuning or application porting.

However, sqlbase2db is intended precisely to avoid the manual basic transfer of the database structure.

Does sqlbase2db support incremental migrations or delta exports?

sqlbase2db is currently designed for complete migration runs.

The tool generates complete scripts for structure, views, data and indexes of the SQLBase source database. For many replacement projects, this reproducible full run is the cleanest and most verifiable approach.

Incremental migrations or delta exports – meaning only data changed since a certain point in time – are currently not part of the standard scope.

If your project requires particularly short cutover times, please contact us. In such cases, the migration strategy should be considered individually, for example through test migrations, planned cutover windows or project-specific procedures.

Ready to move on?

Nobody buys sqlbase2db because they need another command-line tool in their collection.

What they buy is the ability to leave SQLBase behind cleanly, traceably and with significantly less manual work.

Planning a SQLBase migration?

[ Request migration ]

[ View license & pricing ]

sqlbase2db is a product of isential gmbh.
Copyright © 2026 isential gmbh. All rights reserved.

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.