Este apartado es una pequeña guía práctica de portabilidad de aplicaciones construidas con MultiBase en entornos con CTSQL a entornos con servidor Informix-On Line (OL) o Informix-SE (SE).
A) Tipos de datos:
Las conversiones entre los tipos de datos del CTSQL de MultiBase y los
del servidor de base de datos de Informix se realizan de forma automática
según las siguientes tablas:
| CTSQL | Informix |
| CHAR(size) SMALLINT INTEGER DECIMAL(p,s) MONEY(p,s) SERIAL DATE TIME |
CHAR(size) SMALLINT INTEGER DECIMAL(p,s) MONEY(p,s) SERIAL DATE CHAR(11) |
| Informix | CTSQL |
| CHAR(size) SMALLINT INTEGER DECIMAL(p,s) MONEY(p,s) SERIAL DATE DATETIME INTERVAL BYTE (versión 5) TEXT (versión 5) VARCHAR (size) FLOAT SMALLFLOAT |
CHAR(size) SMALLINT INTEGER DECIMAL(p,s) MONEY(p,s) SERIAL DATE CHAR(size) — — — CHAR(size) DECIMAL(p,s) DECIMAL(p,s) |
El programador tendrá que tener en cuenta estas tablas si quiere actualizar el catálogo de MultiBase con una base de datos ya existente en Informix, creando un esquema acorde con las conversiones automáticas que realiza el «gateway» (ver «Casos Prácticos» al final de este documento).
B) Funciones:
Restricciones de funcionalidad:
—Frente a la versión 4 del gestor de Informix: No se pueden utilizar las funciones permitidas por el CTSQL de MultiBase (consulte el epígrafe 2.3 del Manual del SQL de MultiBase) en frases SQL que manejan o devuelven tipos TIME o expresiones de este tipo, al no existir equivalente de las mismas en el gestor de Informix ni posibilidad de generarlas. Esta clase de funciones son «time()», «hour()», «minute()», «second()», «hms()», «mt()» y «tomt()». Asimismo, tampoco puede emplearse la función «typelength».
—Frente a la versión 5 del gestor de Informix:
Permite la creación de procedimientos SQL que se almacenan en la misma base de datos. En este momento, y siguiendo este método, MultiBase crea la función «typelength» de forma automática. El resto podrían ser simuladas siguiendo el mismo mecanismo.
Las funciones SQL propias de Informix pueden utilizarse si se especifican adecuadamente en la sección «.FUNCTIONS» del fichero de configuración.
C) Instrucciones:
—Primera fase de traducción:
Algunas de las diferencias sintácticas existentes en instrucciones
del CTSQL respecto a las del servidor de Informix se resuelven por el «gateway» de
forma transparente al programador en una primera fase de traducción.
Por ejemplo:
«DECLARE CURSOR FOR UPDATE» por «DECLARE CURSOR FOR UPDATE OF <columnas>».
La palabra reservada «TEXT» por «MBTX».
La expresión «NOW» por un literal con la hora del sistema en formato DBTIME (variable de entorno de MultiBase).
Las fases subsiguientes resuelven, de manera particularizada, más diferencias de este tipo, así como el resto de incompatibilidades existentes entre las instrucciones del CTSQL y las del servidor de Informix.
—CREATE DATABASE, DROP DATABASE, START DATABASE y DATABASE.
Estas instrucciones suponen la ejecución automática por parte
del «gateway» de los siguientes pasos:
| CREATE DATABASE | -> | CREATE DATABASE + CREATE MULTIBASE CATALOGS |
| DROP DATABASE | -> | DROP DATABASE + DROP MULTIBASE CATALOGS |
| START DATABASE (SE) | -> | START DATABASE + INSERT ‘SYSLOG’ EN ‘MBTABLES’ |
| START DATABASE (OL) | -> | DATABASE + INSERT ‘SYSLOG’ EN ‘MBTABLES’ |
| DATABASE | -> | DATABASE |
Siendo CREATE MULTIBASE CATALOGS y DROP MULTIBASE CATALOGS instrucciones nuevas de MultiBase disponibles para el programador.
Cada una de las instrucciones anteriores considera los posibles valores de la variable de configuración DBSYN existente en «gwinformix.env» para activar la base de datos correcta.
NOTAS al programador:
El identificador «syslog» hace referencia a un registro especial de la tabla «mbtables» del catálogo cuya existencia indica que la base de datos es transaccional.
En Informix On-Line (OL) el modo de funcionamiento transaccional se adquiere en el momento de la creación, si se especifica, o posteriormente vía administrador. Este último modo ha de reflejarse en el catálogo de MultiBase utilizando «START DATABASE WITH LOG» para mantener su integridad.
—CREATE TABLE.
Frente a la versión 4 del gestor de Informix:
El atributo NOT NULL se mantiene directamente por el SQL de Informix.
El atributo DEFAULT se simula en las operaciones de INSERT cuyos valores en «VALUES» se introduzcan a través de constantes o variables «host». La simulación no funciona cuando los valores se introducen a través de una instrucción SELECT, ya que no es posible controlar su resultado (INSERT… SELECT…).
La cláusula «PRIMARY KEY» se simula de forma automática por el «gateway» a través de la creación de un índice único sobre las columnas especificadas, y cuyo identificador es el nombre de la tabla precedido por «PK».
Restricciones de funcionalidad:
El resto de los atributos y la clave referencial se aceptan gramaticalmente, pero no funcionan al nivel de SQL.
No obstante, la definición de cualquier atributo queda almacenada en los catálogos de MultiBase, con lo que, al nivel de programa (FORM), muchos de ellos siguen teniendo validez (RIGHT, ZEROFILL, etc.), ya que se utiliza esta información como base.
Frente a la versión 5 del gestor de Informix:
El SQL mantiene directamente los atributos CHECK y DEFAULT, además
del NOT NULL. También las cláusulas «PRIMARY KEY» y «FOREIGN
KEY» son manejadas automáticamente, con lo que el «gateway» ya
no tiene que realizar ninguna labor de simulación para ellas.
Restricción de funcionalidad: El resto de atributos no funcionan a nivel de SQL.
Frente a la versión de Informix-Online:
El modo de bloqueo que se asigna por defecto al crear la tabla es por fila,
es decir, «lock mode row», lo que permite la máxima
concurrencia en el acceso a la misma.
NOTA al programador: Si al ejecutar una frase SQL que genera, modifica o borra un objeto de la base de datos se produce un error actualizando el catálogo de MultiBase, éste puede quedar inconsistente, ya que la acción sobre el objeto no se deshace. En este caso es necesario rectificarlo para que cualquier aplicación MultiBase funcione correctamente.
—FETCH CURSOR.
Restricciones de funcionalidad:
En MultiBase, todos los «cursores» permiten el acceso a las filas siguiente, anterior, primera y última (NEXT, PREVIOUS, FIRST, LAST).
Frente a Informix, este tipo de operaciones se restringe a los «cursores» que no hayan sido definidos «FOR UPDATE».
Frente a la versión de Informix-SE:
Por razones de eficacia, en modo transaccional los «cursores» secuenciales (todos aquellos que no realicen operaciones de tipo «scroll» y que no sean «FOR UPDATE») son definidos por el «gateway» como «cursores scroll» de Informix.
En modo no transaccional, los «cursores scroll» (aquellos que realicen operaciones de tipo «scroll» y que no sean «FOR UPDATE») son simulados por el «gateway» en base a «cursores» secuenciales de Informix. Para ello emplea un fichero secuencial («SCRnnnnpid.GW») donde realiza el «scroll» necesario de los registros seleccionados.
Las SELECT directas siempre se definen sobre «cursores» secuenciales de Informix.
Frente a la versión de Informix-Online.
Por razones de eficacia, en modo transaccional los «cursores» secuenciales (todos aquellos que no realicen operaciones de tipo «scroll» y que no sean «FOR UPDATE») son definidos por el «gateway» como «cursores scroll» de Informix.
Las SELECT directas siempre se definen sobre «cursores» secuenciales de Informix.
—LOCK TABLE.
Si el servidor de Informix se encuentra funcionando en modo transaccional,
la instrucción LOCK TABLE será capaz de bloquear una tabla
si se encuentra dentro de una transacción. Bajo este modo será la
instrucción COMMIT WORK la que produzca el mismo efecto que UNLOCK
TABLE.
—OPEN CURSOR.
Los identificadores de CURSOR han de tener como máximo 15 caracteres
en lugar de 18, que es el máximo permitido por CTSQL para cualquier
identificador de la base de datos (frente a cualquier SQL). Esta pequeña
restricción permite seguir diferenciando «cursores» con
el mismo nombre en diferentes módulos CTL, aspecto éste que
sólo sabe manejar el CTSQL.
—SELECT… FROM…
El «gateway» está simulando el comportamiento de CTSQL
en un «SELECT {MIN,MAX,AVG,SUM}» sin «GROUP BY» (ya
que Informix devuelve una fila con valor «NULL» si el número
de filas seleccionadas es cero, mientras que MultiBase no devuelve nada),
con la salvedad de que el programador no puede distinguir el caso de una
selección de filas con valores nulos (aunque esto no es habitual).
—UNLOCK TABLE.
En modo transaccional, para conseguir el desbloqueo de una tabla ha de
realizarse el «COMMIT» de la transacción dentro de
la cual se hizo el bloqueo de la misma (ver comentarios sobre la instrucción
LOCK TABLE).
D) Otros:
—Tablas compartidas: Si las bases de datos son transaccionales es
posible compartir tablas entre ellas. Para ello se deberá proceder
como sigue: Desde el gestor de Informix ha de crearse el sinónimo «CREATE
SYNONYM "nombre" FOR "base_datos_propietaria:nombre_tabla"» en
la base de datos desde la cual se desea acceder. Los permisos deberán
otorgarse de acuerdo a la operación a realizar. A continuación,
desde MultiBase, ha de crearse dicha tabla en modo mantenimiento para que
la descripción figure en el catálogo de MultiWay.