Compatibilidad Interbase 6 / Firebird 2.0

[josemmerida]

Tengo un programa desarrollado en delphi5/FIB+ contra servidores Interbase 6.0, en funcionamiento desde hace 5 años. Todo bien .

Despues de leer mucho sobre las bondades de Firebird me he decidido de una vez por todas a cambiar. Entiendo que de la siguiente forma:
(Por ahora no voy a cambiar nada en mi programa)

-Desinstalar en los servidores Interbase, asegurandome que no quede ninguna version de gds32.dll.

-Instalar en los servidores Firebird 2.0, con la opcion de compatibilidad de gds32.dll.

-Desinstalar de todos los clientes las librerias de Interbase, asegurandome que no quede ninguna version de gds32.dll.

-Instalar en los clientes Firebird 2.0 la parte cliente.

- Y...Entiendo que lo que no es necesario es hacer un backup transportable para hacer un restore luego, porque si accedo a traves de la nueva GDS32.dll se mantiene el ODS10. ¿Es esto correcto?

¿Si es cierto esto? ¿Queda esta Base de Datos compatible con Interbase si tengo que volver atras?.

He probado a conectar en local en el servidor, y lo hace sin problemas, me da version del servidor WI 6.3.xxxx, pero no me atrevo a seguir sin confirmarlo....

Gracias a todos

[fdelamo]

Hola,

la verdad es que en cuestión de librerías no se decirte, pero hace tiempo nos pasamos de Interbase 6.0 a Firebird 1.XX y tuvimos que cambiar alguna query
(quizá por la configuración, no lo sé), pero no te cuesta nada probar esto:

Por ejemplo, la consulta:

Código SQL [-]
SELECT A.*, B.* 
FROM A 
INNER JOIN B ON (A.ID = B.ID)
WHERE ID = 1

en Interbase funciona y en Firebird no (no recuerdo el error exacto que daba pero era algo así como que no sabía el campo de que tabla nos referíamos, ya que existe en A y en B).

Pruebalo, por que quizá sea configuración (o yo que lo he soñado), pero por si acaso ...

[[ArdiIIa]]

Hace tiempo un cliente "remoto", que funcionaba con INTERBASE, tuvo que cambiar de ordenadores y tras instalar FIREBIRD, todo siguió funcionando perfectamente, sin cambio alguno (y así sigue). Con esto entiendo que la compatibilidad ha de ser absoluta. No obstante si te surgen dudas, puedes probar a utilizar en otro ordenador tus bases de datos Interbase, pero con Firebird, creo que el resultado será óptimo..

[[Lepe]]

josenmerida, nada de miedos, primero una copia de la BBDD en CD y después "avante claro" .

saludos y suerte

[josemmerida]

Im-pre-sio-nan-te.

Lo he hecho. He cambiado a Firebird.

Tengo a 25 usuarios dandome palmaditas (cariñosas ) en la espalda. Esto vuela. Algún proceso, con algunas tablas mal diseñadas (...era muy joven...) que tardaba un par de minutos, ahora no tarda más de 20 segundos, con el mismo penoso diseño. Merece la pena perder 2 días en ajustar un par de 'cosillas'.

Gracias Firebird 2.0 ...y a todos los que me habeis animado.

Explico los detalles que me han frenado un poco por si a alguien le sirve:

Al hacer el restore en Firebird, algunas tablas se me quedaban solo lectura, esto era porque tenia en ellas alguna asignacion del tiponew.campo=Variable en algun triger After Post o After Insert
y esto hace que si intentas recompilar el Triger falle. Lo mismo pasa con selecciones del tipo select a,b from tabla order by c en Interbase estaban permitidas en Firebird no, o añades el campo por el que quieres ordenar, o cambias el ampo del orden.

....y nada más.

Saludos y Gracias.

[Casimiro Notevi]

Empezado por josemmerida[..

Al hacer el restore en Firebird, algunas tablas se me quedaban solo lectura, esto era porque tenia en ellas alguna asignacion del tipo new.campo=Variable en algun triger After Post o After Insert
y esto hace que si intentas recompilar el Triger falle.[..]

En mi empresa seguimos montando todavía la v1.5 y pronto vamos a estudiar la versión 2.
Por curiosidad: a qué te refieres exactamente con ese problema "new.campo=variable"?, cómo asignas ahora el valor, cómo lo has solucionado?

[[ArdiIIa]]

Empezado por josemmerida

Im-pre-sio-nan-te.

Lo mismo pasa con selecciones del tipo select a,b from tabla order by c en Interbase estaban permitidas en Firebird no, o añades el campo por el que quieres ordenar, o cambias el ampo del orden.
Saludos y Gracias.

La versión DOS aporta nueva e interesantes extensiones tal como esta:

Código SQL [-]
EXECUTE STATEMENT  'SELECT COUNT(*) FROM  ' || TABLA || 'order by ' || campo

Super potente pero... EXECUTE STATEMENT is potentially dangerous, because:
........
.....
...
..

[lbuelvas]

Si hay algunas diferencias entre Interbase 6.0 y Firebird. Hablare de Firebird 1.5.3 pues no he migrado apliaciones a la version 1.5.4 o 2.0 hasta ver que el producto ande mas estable, entendiendo por mas estable que no aparezca algun bug que afecte directamente el comportamiento de mis aplicaciones.

Muy respetuosamente y a pesar del excelente trabajo de quienes estan construyuendo el producto Firebird, han aparecido defectos por correccion de otros defectos, entonces uno debe ser un poco responsable con el cliente y no lanzarse a cambiar de versiones del motor de base de datos por el simple hecho que aparece una nueva version, yo ya he tenido problemas con eso.

Una de las diferencias esta en las consultas, Firebird es muy exigente (cosa que me alegra) cuando se hacen consultas con uniones (joins) si las tablas que participan contienen nombre de columnas iguales, debe explicitamente indicarse a que tabla se hare referencia en la consulta. Por ejemplo dada las siguientes tablas y con datos:

Código SQL [-]
CREATE TABLE TABLA_A (
    ID_A   INTEGER NOT NULL,
    VALOR  VARCHAR(10) NOT NULL
);


CREATE TABLE TABLA_B (
    ID_B   INTEGER NOT NULL,
    ID_A   INTEGER,
    VALOR  VARCHAR(10)
);


INSERT INTO TABLA_A (ID_A, VALOR) VALUES (1, 'CASO X');
INSERT INTO TABLA_A (ID_A, VALOR) VALUES (2, 'CASO Y');
INSERT INTO TABLA_A (ID_A, VALOR) VALUES (3, 'CASO Z');

COMMIT WORK;

INSERT INTO TABLA_B (ID_B, ID_A, VALOR) VALUES (1, 1, 'A');
INSERT INTO TABLA_B (ID_B, ID_A, VALOR) VALUES (2, 1, 'B');
INSERT INTO TABLA_B (ID_B, ID_A, VALOR) VALUES (3, 1, 'C');

COMMIT WORK;

ALTER TABLE TABLA_A ADD CONSTRAINT PK_TABLA_A PRIMARY KEY (ID_A);
ALTER TABLE TABLA_B ADD CONSTRAINT PK_TABLA_B PRIMARY KEY (ID_B);
ALTER TABLE TABLA_B ADD CONSTRAINT FK_TABLAB_TABLAA FOREIGN KEY (ID_A) REFERENCES TABLA_A (ID_A);

La siguiente consulta

Código SQL [-]
select id_a, a.valor, b.valor
from       tabla_a a
inner join tabla_b b on (a.id_a = b.id_b)

generar el error: Ambiguous field name between table TABLA_A and table TABLA_B. ID_A.

Para corregrilo debe indicarse de que tabla debe tomar el valor del campo id_a asi:

Código SQL [-]
select a.id_a, a.valor, b.valor
from       tabla_a a
inner join tabla_b b on (a.id_a = b.id_b)

Hay otra diferencia entre las versiones 1.5.2 y 1.5.3 de Firebird, resulta que en el hilo
http://www.clubdelphi.com/foros/showthread.php?t=22117, sugeri con Firebird 1.5.2 hacer una especie de Break en un procedimiento almacenado y me funciono. Pero en Firebird 1.5.3 ya no funciona, pues existen las sentencias LEAVE y BREAK, disponibles desde la version 1.5.

[josemmerida]

Me refiero a que en un Triger After no se puede asignar valor a la variable de campo new. En Interbase se podia hacer pero no tenia ningun efecto sobre el valor del campo. En Firebird ya no se puede hacer. Por supuesto en los triger Before si.

Saludos.

[Casimiro Notevi]

Empezado por josemmerida

Me refiero a que en un Triger After no se puede asignar valor a la variable de campo new. En Interbase se podia hacer pero no tenia ningun efecto sobre el valor del campo. En Firebird ya no se puede hacer. Por supuesto en los triger Before si.

Saludos.

Ok, gracias, había entendido otra cosa, ahora está claro