Compatibilidad Interbase 6 / Firebird 2.0

[[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 Noteví]

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 Noteví]

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