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.