Migración automatizada de bases de datos Gupta SQLBase a Microsoft SQL Server, PostgreSQL, MySQL y MariaDB, incluida la estructura, las vistas, los datos y los índices. Local. Reproducible. Sin trabajo manual sobre el esquema.

Gupta SQLBase ha funcionado de manera confiable durante décadas en muchas empresas. Ese no es el problema.

El problema comienza cuando se necesitan aplicaciones modernas, arquitecturas .NET actuales, plataformas de bases de datos flexibles y modelos de licenciamiento razonables.

sqlbase2db ayuda a migrar de forma ordenada las bases de datos SQLBase existentes a sistemas de destino modernos, sin dedicar semanas de trabajo manual a tablas, tipos de datos, vistas, exportaciones de datos y definiciones de índices.

Sistemas de destino compatibles actualmente

• Microsoft SQL Server
• PostgreSQL

Otros sistemas de destino ya están firmemente planificados:

• MySQL
• MariaDB

La compatibilidad con MySQL y MariaDB se encuentra actualmente en preparación. Si su sistema de destino no aparece en esta lista, contáctenos. En muchos casos podemos evaluar si resulta conveniente desarrollar una extensión o una implementación específica para el proyecto.

[ Solicitar una migración ]

[ Ver licencias y precios ]

Por qué SQLBase puede convertirse hoy en un cuello de botella

SQLBase ha sido y continúa siendo una base de datos confiable para muchas aplicaciones. Numerosos sistemas llevan años, e incluso décadas, funcionando con ella. Precisamente por eso, las instalaciones de SQLBase suelen ser críticas para el negocio.

Pero los sistemas heredados estables tienen una costumbre desagradable:

Siguen funcionando durante un tiempo sorprendentemente largo, hasta que la modernización deja de ser opcional de repente.

Por lo general, las empresas desean reemplazar SQLBase por tres razones.

1. Modernización técnica

Las arquitecturas .NET modernas necesitan una integración moderna con la base de datos

Muchas aplicaciones .NET actuales utilizan tecnologías ORM como Entity Framework Core. Para ello se necesitan proveedores de bases de datos adecuados. Microsoft enumera numerosos proveedores para EF Core, entre ellos SQL Server, PostgreSQL, SQLite, MySQL/MariaDB y Oracle. SQLBase no figura entre los proveedores estándar habituales.

Proveedores de bases de datos – learn.microsoft.com

En la práctica, esto significa:

• no existe una vía estándar y limpia para Entity Framework Core;
• se necesita más lógica de acceso a datos desarrollada a medida;
• se depende de capas de acceso clásicas, como ODBC, o de proveedores de datos antiguos;
• aumenta el esfuerzo necesario para la refactorización, el nuevo desarrollo y la modernización;
• hay una menor adecuación a los modelos actuales de desarrollo .NET.

En resumen:

SQLBase funciona.

Pero cada vez encaja con menos comodidad en los entornos .NET modernos.

Y, por supuesto, casi todo puede mantenerse con vida de alguna manera.

También es posible visitar a los clientes todos los días en un automóvil clásico. La única pregunta es si eso puede considerarse una estrategia de movilidad.

2. Razones económicas

Las licencias de bases de datos no son un detalle menor

En los entornos de producción habituales, SQLBase representa un factor de costo adicional. Debe considerarse en cada instalación, cada ampliación y cada implementación para un cliente.

Esto se nota especialmente en instalaciones pequeñas, de aproximadamente 5 a 25 usuarios. La aplicación puede ser eficiente, pero la licencia de la base de datos sigue encareciendo el paquete completo.

Los sistemas de destino modernos ofrecen mayor flexibilidad:

• Microsoft SQL Server Express es una edición gratuita de SQL Server para aplicaciones pequeñas de escritorio, web y servidor.
  Microsoft® SQL Server® 2022 Express – microsoft.com
  
  
• PostgreSQL se publica bajo una licencia de código abierto permisiva y puede utilizarse, copiarse, modificarse y distribuirse sin costos de licencia.
  PostgreSQL License – postgresql.org
  
  
• MySQL y MariaDB están planificados como sistemas de destino adicionales y ampliarán aún más las opciones disponibles.

De este modo, la base de datos deja de convertirse automáticamente en un factor de costo.

En muchos casos, la migración puede amortizarse simplemente al evitar futuros costos de licencias de SQLBase o reducir de forma considerable los gastos de licenciamiento de la base de datos.

3. Libertad estratégica

Más plataformas. Más herramientas. Más opciones.

Migrar de SQLBase a SQL Server o PostgreSQL no consiste únicamente en reemplazar técnicamente una base de datos.

La migración abre la puerta a un ecosistema más amplio:

• mejor integración con aplicaciones modernas;
• mayor compatibilidad con herramientas de desarrollo;
• más conocimientos especializados disponibles en el mercado;
• herramientas modernas de administración y supervisión;
• mejores opciones de respaldo, operación y escalabilidad;
• integración más sencilla en entornos de nube, contenedores y DevOps;
• menor dependencia de una tecnología especializada y envejecida;
• futuras plataformas de destino adicionales mediante MySQL y MariaDB.

Esto reduce los riesgos del proyecto a largo plazo.

Y, como todos sabemos, los riesgos de TI rara vez se vuelven costosos cuando se detectan. Se vuelven costosos cuando se ignoran durante años.

Qué hace sqlbase2db

sqlbase2db es una herramienta profesional de línea de comandos para la migración automatizada de bases de datos Gupta SQLBase.

El programa lee la base de datos SQLBase de origen y genera scripts SQL ejecutables para el sistema de destino.

No se limita a exportar los datos. También migra la estructura de la base de datos, las vistas y los índices.

Exportación automatizada del esquema

sqlbase2db analiza la estructura de las tablas de la base de datos SQLBase y la traduce a la sintaxis del sistema de destino.

Entre otros elementos, procesa:

• tablas;
• columnas;
• tipos de datos;
• longitudes y precisión;
• definiciones NULL / NOT NULL;
• vistas;
• particularidades técnicas de la plataforma de destino.

El objetivo es obtener una estructura ejecutable en SQL Server o PostgreSQL, sin tener que reconstruir manualmente la base de datos.

Las vistas también se migran

Las vistas existentes de SQLBase se consideran durante la exportación del esquema y se transfieren al sistema de destino, siempre que puedan representarse de manera técnica e inequívoca.

En el caso de vistas sencillas, esto suele ser directo. Las vistas más complejas pueden contener sintaxis específica de SQLBase, por ejemplo, funciones propietarias, concatenaciones especiales de cadenas o expresiones específicas de la base de datos.

Después de la migración, estas vistas deben revisarse desde el punto de vista funcional y técnico. sqlbase2db realiza la transferencia estructural, pero no sustituye la evaluación funcional de la lógica de aplicación específica de una base de datos.

Eso no es una deficiencia. Es simplemente la realidad de los dialectos SQL. Quien prometa lo contrario tiene un ejemplo muy pequeño o una cantidad extraordinaria de optimismo.

Exportación completa de los datos

Después de exportar el esquema, sqlbase2db exporta los datos de las tablas de SQLBase.

sqlbase2db genera scripts INSERT ejecutables y gestiona obstáculos habituales:

• caracteres especiales;
• valores de fecha y hora;
• valores NULL;
• formatos numéricos;
• datos binarios;
• grandes volúmenes de datos;
• comportamientos específicos de SQLBase.

La exportación es reproducible y trazable.

Gestión del ROWID de SQLBase

Gupta SQLBase trabaja internamente con un ROWID, que suele desempeñar un papel práctico en las aplicaciones existentes, a veces de forma explícita y otras como consecuencia de la evolución histórica del sistema.

Al migrar a SQL Server, PostgreSQL u otros sistemas de destino modernos, no puede suponerse que este ROWID exista como un concepto interno idéntico. Otras bases de datos utilizan mecanismos y garantías diferentes, y tienen otra concepción de lo que debe ser una dirección interna de fila.

sqlbase2db tiene en cuenta esta cuestión y ofrece una solución específica:

• los valores ROWID de SQLBase pueden detectarse y considerarse durante la exportación;
• si es necesario, puede crearse una columna técnica de reemplazo en el sistema de destino;
• las referencias existentes al ROWID pueden transferirse de forma más transparente al nuevo entorno;
• la estructura de destino permanece transparente y verificable.

Esto evita que una particularidad interna de SQLBase se convierta silenciosamente en una mina durante la migración.

Sin embargo, si una aplicación depende en gran medida de la lógica ROWID de SQLBase, este aspecto debe revisarse expresamente durante la migración de la aplicación. sqlbase2db elimina el obstáculo técnico, pero solo la propia aplicación puede determinar su significado funcional.

Exportación de índices y restricciones

Después de la estructura y los datos, sqlbase2db genera los scripts para los índices y las restricciones de unicidad.

Esta separación es intencional, ya que en los proyectos de migración suele ser más conveniente crear primero la estructura, cargar después los datos y construir finalmente los índices.

El resultado es un proceso limpio y controlable.

Qué no se migra automáticamente de forma intencional

sqlbase2db se concentra en migrar de manera confiable:

• estructuras de tablas;
• vistas;
• datos;
• índices;
• restricciones de unicidad.

Los desencadenadores y los procedimientos almacenados no se migran automáticamente.

Si la base de datos SQLBase contiene desencadenadores o procedimientos almacenados, deberán revisarse manualmente y, si corresponde, recrearse en el sistema de destino.

La razón es sencilla: estos objetos suelen contener lógica, sintaxis y efectos secundarios específicos de la base de datos. En muchos casos, una traducción automática uno a uno no sería confiable. Y la falta de confiabilidad es algo que otros saben hacer mejor.

En lugar de generar silenciosamente scripts de destino dudosos, sqlbase2db mantiene aquí una transparencia deliberada.

Archivos de salida claramente separados

sqlbase2db genera archivos independientes para cada etapa de la migración.

Ejemplo para SQL Server:

Archivo	Descripción
mssql_meinedb_01_schema.sql	Crear la estructura de tablas y las vistas
mssql_meinedb_02_data.sql	Cargar los datos
mssql_meinedb_03_indexes.sql	Crear índices y restricciones
mssql_readme.txt	Instrucciones paso a paso

En forma analógica se generan los archivos correspondientes para PostgreSQL.

De este modo, la migración es transparente, verificable y repetible.

Proceso habitual

1. Conectarse a la base de datos SQLBase
   sqlbase2db accede a la base de datos de origen mediante el cliente SQLBase instalado.
2. Seleccionar el sistema de destino
   Actualmente, Microsoft SQL Server o PostgreSQL. MySQL y MariaDB están planificados como sistemas adicionales.
3. Iniciar la exportación
   La herramienta lee la estructura, las vistas, los datos y los índices.
4. Revisar los scripts SQL
   Los archivos generados pueden versionarse, revisarse y documentarse.
5. Ejecutar los scripts en el sistema de destino
   El esquema, los datos y los índices se importan en un orden definido.
6. Revisar los desencadenadores y procedimientos almacenados
   Si existen, se evalúan desde el punto de vista funcional y técnico y se recrean manualmente en el sistema de destino.
7. Cambiar y probar la aplicación
   La base de datos migrada queda disponible para la modernización, la portabilidad o la continuidad de la operación.

Cómo se realiza una migración con sqlbase2db

sqlbase2db es una herramienta de línea de comandos.

La migración se inicia con una instrucción clara y genera archivos SQL separados para la estructura, los datos y los índices.

Los siguientes ejemplos están abreviados con fines ilustrativos. En migraciones reales, sqlbase2db genera scripts completos para todas las tablas, vistas, datos e índices compatibles de la base de datos SQLBase.

Ejemplo: inicio desde la línea de comandos

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

O para Microsoft SQL Server:

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

La sintaxis exacta puede variar según la versión.

El principio se mantiene: indicar el origen, seleccionar el sistema de destino, definir el directorio de salida e iniciar la migración.

Ejemplo: salida de la consola

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. 

Esta salida muestra intencionalmente no solo el caso satisfactorio, sino también las indicaciones relevantes:

• se detectan las vistas;
• se gestiona el ROWID;
• se informa de manera transparente sobre los desencadenadores y procedimientos almacenados.

Ejemplo: archivos generados

C:\migration\meinedb\

  pgsql_meinedb_01_schema.sql   Create table structure and views
  pgsql_meinedb_02_data.sql     Load data
  pgsql_meinedb_03_indexes.sql  Create indexes and constraints 
  pgsql_readme.txt              Step-by-step instructions 

Para Microsoft SQL Server se generan los archivos correspondientes con el prefijo mssql_.

Ejemplo: extracto de 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
); 

El encabezado del archivo muestra claramente la licencia, el sistema de origen y el sistema de destino utilizados para generar el script.

La columna técnica sqlbase_rowid es un ejemplo de cómo la información ROWID de SQLBase puede transferirse de forma transparente a la estructura de destino cuando sea necesario.

Ejemplo: extracto de una vista

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

Por lo tanto, las vistas no quedan ocultas, sino que aparecen como una parte visible de la migración del esquema.

Nota:
En el caso de definiciones de vistas complejas y específicas de SQLBase, puede ser conveniente realizar una revisión funcional después de la migración.

Ejemplo: extracto de 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;

Este ejemplo muestra:

• una estructura INSERT legible;
• una salida segura mediante transacciones;
• una transferencia de datos trazable;
• la gestión del ROWID, si es necesaria.

Ejemplo: extracto de indexes.sql

CREATE UNIQUE INDEX ux_kunden_kunden_nr
ON kunden (kunden_nr);

CREATE INDEX ix_kunden_name
ON kunden (name); 

Los índices y las restricciones de unicidad se generan intencionalmente por separado, después de importar la estructura y los datos.

En los proyectos de migración, este procedimiento suele ser más conveniente, rápido y fácil de controlar.

Ejemplo: extracto de 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.

El archivo Léame documenta el orden de ejecución y señala los elementos que deben revisarse expresamente en el sistema de destino.

Ejecución local en lugar de la nube

sqlbase2db se ejecuta localmente en su entorno.

Sus bases de datos de producción no se cargan en nuestros sistemas.

No existe una migración en la nube, no se cargan sus datos de SQLBase ni se procesan externamente.

La comunicación en línea se utiliza exclusivamente para verificar y activar la licencia.

Esto es especialmente importante para:

• datos empresariales de producción;
• bases de datos de clientes;
• sectores sensibles;
• requisitos internos de cumplimiento;
• proveedores de servicios que trabajan con datos de clientes.

En resumen: sus datos permanecen donde deben estar, bajo su control.

¿A quién está dirigido sqlbase2db?

sqlbase2db está dirigido a empresas y proveedores de servicios que ya no desean mantener SQLBase como un cuello de botella técnico o económico.

Entre los usuarios habituales se encuentran:

• empresas con aplicaciones SQLBase existentes;
• proveedores de ERP y empresas de software con instalaciones heredadas de SQLBase;
• proveedores de servicios de TI con proyectos de migración de SQLBase;
• equipos de desarrollo que modernizan aplicaciones existentes;
• operadores de soluciones sectoriales con numerosas bases de datos de clientes;
• organizaciones que desean reducir los costos de licencias de SQLBase;
• usuarios que planean utilizar SQL Server, PostgreSQL, MySQL o MariaDB como plataformas estratégicas de bases de datos.

sqlbase2db fue desarrollado para proyectos serios de sustitución y modernización.

De manera intencional, no está optimizado para exportaciones individuales improvisadas, pruebas experimentales ni proyectos del tipo «veamos si quizá algún día migramos».

Esto ahorra tiempo. A ambas partes.

Desarrollado a partir de la experiencia práctica con SQLBase

Detrás de sqlbase2db se encuentra isential gmbh, con alrededor de 36 años de experiencia práctica en el uso de Gupta SQLBase.

No conocemos SQLBase por sus fichas técnicas.

Lo conocemos por aplicaciones reales, instalaciones reales de clientes y problemas reales de migración.

Esta experiencia es importante porque las migraciones de SQLBase rara vez fallan por los aspectos evidentes.

La tabla CUSTOMERS no es el problema. El problema está en los detalles:

• tipos de datos;
• caracteres especiales;
• conjuntos de datos antiguos;
• estructuras desarrolladas a lo largo de los años;
• vistas;
• índices;
• ROWID;
• comportamientos propietarios;
• tablas de gran tamaño;
• datos de producción con un historial muy extenso;
• desencadenadores y procedimientos almacenados que deben tratarse por separado de forma intencional.

Por eso, sqlbase2db no es un producto de laboratorio, sino una herramienta desarrollada a partir de la práctica.

O, dicho de forma más breve: no vendemos magia. Simplemente eliminamos el tedioso trabajo manual de un proyecto en el que dicho trabajo puede resultar sorprendentemente costoso.

Ventajas frente a una migración manual

Una migración manual de SQLBase es posible.

También es posible quitar azulejos con una navaja de bolsillo.

La única pregunta es si realmente desea hacerlo.

sqlbase2db reduce los riesgos habituales de las migraciones manuales:

Menos trabajo manual sobre el esquema

Las tablas, columnas, vistas y tipos de datos no tienen que transferirse uno por uno.

Resultados reproducibles

La migración puede repetirse, revisarse y documentarse.

Separación clara de las etapas

El esquema, los datos y los índices se generan por separado.

Menos fuentes de error

Los caracteres especiales, los valores de fecha, los datos binarios, los valores NULL y las particularidades de SQLBase se gestionan de forma sistemática.

Gestión transparente de las limitaciones

Los desencadenadores y procedimientos almacenados no se traducen automáticamente, sino que se tratan expresamente como lógica de base de datos que requiere una revisión manual.

Mejor planificación

Las migraciones de prueba y las ejecuciones de producción pueden realizarse con los mismos mecanismos.

Menor esfuerzo del proyecto

La migración real deja de convertirse en un proyecto de semanas de trabajo manual.

Licencias y precios

Preferimos precios claros a una niebla de precios.

sqlbase2db es una herramienta profesional para proyectos de migración en producción. El modelo de licenciamiento es deliberadamente sencillo:

• licencia de uso perpetua;
• facturación por unidades de migración;
• varias migraciones incluidas en la licencia básica;
• uso local;
• verificación periódica en línea para vincular la licencia;
• sin transferencia de sus datos a la nube.

¿Qué es una unidad de migración?

Una unidad de migración es la migración completa de una instancia de base de datos SQLBase técnicamente independiente, compuesta por la estructura, las vistas, los datos y los índices, a una base de datos de destino.

Importante:

• el nombre de la base de datos por sí solo no es determinante;
• una estructura idéntica no significa que se trate de la misma base de datos;
• varias bases de datos de clientes con la misma estructura son unidades de migración independientes;
• las ejecuciones de prueba repetidas de una misma base de datos no deben contabilizarse artificialmente varias veces.

Por lo tanto, el licenciamiento se basa en el valor real de la migración, no en nombres de archivos arbitrarios.

Licencia básica

4.500 € como pago único

Incluye:

• licencia de uso perpetua;
• 3 unidades de migración completas;
• sistemas de destino: Microsoft SQL Server y PostgreSQL;
• MySQL y MariaDB cuando estén disponibles los módulos correspondientes;
• ejecución local;
• sin transferencia de datos a la nube;
• generación completa de scripts y documentación;
• información de la licencia en los archivos de salida generados;
• verificación periódica en línea para garantizar la vinculación de la licencia.

La licencia básica está diseñada para proyectos de migración habituales y, en muchos casos, cubre las ejecuciones de prueba, el ensayo general y la migración de producción.

Migraciones adicionales

En proyectos con varias instancias de bases de datos, pueden adquirirse posteriormente unidades de migración adicionales.

Anzahl	Beschreibung	Preis
1	Migración adicional	1.200 €
5	Migraciones adicionales	5.000 €
10	Migraciones adicionales	9.000 €

Las migraciones adicionales pueden añadirse en cualquier momento y utilizarse después de su activación.

Licencias por proyecto y por volumen

Para proyectos de sustitución más amplios, proveedores de servicios de TI o entornos con numerosos clientes, ofrecemos licencias por proyecto y por volumen.

Estas licencias se definen claramente y se acuerdan según cada proyecto, por ejemplo, para:

• proyectos de clientes definidos;
• entornos con numerosos clientes;
• proveedores de servicios con varios clientes que utilizan SQLBase;
• empresas de software con numerosas instalaciones;
• sistemas de destino fuera del alcance estándar.

Contáctenos si su escenario no se ajusta a los modelos estándar.

Somos pragmáticos, pero no arbitrarios.

Requisitos técnicos

Actualmente, sqlbase2db se ejecuta en Windows porque el acceso a Gupta SQLBase en los entornos existentes habituales se realiza mediante el cliente SQLBase instalado.

Los scripts SQL generados son independientes de Windows y pueden ejecutarse posteriormente en el sistema de destino correspondiente, versionarse o integrarse en procesos de implementación existentes.

Para utilizar sqlbase2db se necesita:

• Windows;
• el cliente Gupta SQLBase instalado;
• acceso de red a la base de datos SQLBase de origen;
• .NET Runtime;
• acceso al sistema de destino Microsoft SQL Server o PostgreSQL.

Sistemas de destino adicionales:

• MySQL, en preparación;
• MariaDB, en preparación.

Si necesita otra base de datos de destino, contáctenos. Con gusto evaluaremos si la compatibilidad puede implementarse de una forma técnica y económicamente razonable.

Preguntas frecuentes

¿Se transferirán nuestros datos a isentia?

No.

sqlbase2db se ejecuta localmente en su entorno. Sus bases de datos SQLBase no se cargan ni se procesan en nuestros sistemas.

La comunicación en línea se utiliza exclusivamente para verificar y activar la licencia.

¿La licencia tiene una duración limitada?

No.

La licencia de uso es perpetua. La vinculación de la licencia se verifica periódicamente en línea.

¿Por qué la licencia básica incluye varias migraciones?

Los proyectos reales suelen incluir una migración de prueba, un ensayo general y una migración de producción.

El modelo de licencia está diseñado para reflejar esta realidad sin contabilizar artificialmente cada repetición técnica.

¿Por qué el licenciamiento se basa en instancias de bases de datos?

Porque cada base de datos técnicamente independiente representa una migración propia, incluso si varias bases de datos utilizan la misma estructura.

El licenciamiento se basa en el valor real de la migración y no únicamente en el nombre o el esquema de la base de datos.

¿Existe una versión de prueba gratuita?

No.

 

sqlbase2db está diseñado para proyectos de migración reales y productivos.

 

Contáctenos y revisaremos conjuntamente su base de datos, el sistema de destino y el alcance del proyecto para determinar la solución adecuada.

¿sqlbase2db también es compatible con MySQL o MariaDB?

La compatibilidad con MySQL y MariaDB está en preparación.

Los sistemas de destino compatibles actualmente son Microsoft SQL Server y PostgreSQL.

Si su proyecto requiere MySQL o MariaDB como sistema de destino, póngase en contacto con nosotros. Dependiendo de la fase en la que se encuentre el proyecto, puede ser conveniente coordinarse con nosotros desde el principio.

¿Qué sucede con otras bases de datos de destino?

Consúltenos. Evaluaremos si resulta técnica y económicamente razonable desarrollar la compatibilidad correspondiente o una solución específica para su proyecto.

sqlbase2db está diseñado para permitir, en principio, la incorporación de otros sistemas de destino. La conveniencia de hacerlo en cada caso concreto dependerá del sistema de destino deseado, del tamaño de la base de datos SQLBase y del contexto del proyecto.

¿Se migran las vistas?

Sí, siempre que puedan transferirse de forma técnica e inequívoca. Las vistas complejas con sintaxis específica de SQLBase deben revisarse desde el punto de vista funcional y técnico después de la migración.

¿Qué sucede con el ROWID de SQLBase?

SQLBase-ROWID es una particularidad que debe abordarse conscientemente durante las migraciones.

sqlbase2db contempla los escenarios dependientes de ROWID y, si es necesario, puede generar una solución técnica de reemplazo transparente en el sistema de destino.

Si su aplicación depende en gran medida de ROWID, este aspecto debería revisarse adicionalmente en el marco de la conversión de la aplicación.

¿Se migran los desencadenadores y procedimientos almacenados?

No.

Los triggers y procedimientos almacenados a menudo contienen lógica de aplicación real. Esta lógica suele estar estrechamente ligada al dialecto SQL, al comportamiento transaccional y a las funciones de la base de datos correspondiente.

Una traducción automática a otro sistema de destino no sería lo suficientemente confiable en muchos casos. Por esta razón, sqlbase2db deliberadamente no migra automáticamente los triggers y procedimientos almacenados.

Los triggers y procedimientos almacenados existentes se identifican y detallan, pero deben revisarse técnicamente y configurarse de forma manual en el sistema de destino.

¿Es necesario repasar manualmente la estructura de destino?

El objetivo de sqlbase2db es transferir de forma automatizada la estructura de SQLBase a scripts SQL ejecutables para el sistema de destino.

Dependiendo de la aplicación, posteriormente puede ser conveniente realizar una optimización técnica o funcional, por ejemplo, en el marco de una modernización, ajuste de rendimiento o portabilidad de la aplicación.

Sin embargo, sqlbase2db busca precisamente evitar la transferencia manual básica de la estructura de la base de datos.

¿Admite sqlbase2db migraciones incrementales o exportaciones delta?

Actualmente, sqlbase2db está diseñado para ejecuciones de migración completas.

La herramienta genera scripts completos para la estructura, vistas, datos e índices de la base de datos de origen SQLBase. Para muchos proyectos de sustitución, este proceso completo y reproducible es precisamente la vía más limpia y verificable.

Las migraciones incrementales o las exportaciones delta (es decir, solo los datos modificados a partir de un momento determinado) no forman parte del alcance estándar en este momento.

Si su proyecto requiere tiempos de conmutación especialmente cortos, contáctenos. En tales casos, la estrategia de migración debe analizarse de forma individual, por ejemplo, a través de migraciones de prueba, ventanas de conmutación planificadas o procedimientos específicos del proyecto.

¿Listo para el cambio?

Nadie compra sqlbase2db porque necesite otra herramienta de línea de comandos en su colección.

Lo que se adquiere es la posibilidad de dejar atrás SQLBase de forma limpia, clara y con mucho menos trabajo manual.

¿Está planificando una migración de SQLBase?

[ Solicitar migración ]

[ Ver licencias y precios ]

sqlbase2db es un producto de isential gmbh.
Copyright © 2026 isential gmbh. Todos los derechos reservados.

 

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.