Ocultar código de Stored Procedures y Triggers en FireBird...

[jncrls]

Hola a todos...

Alguien sabe cómo se puede ocultar el código de los trigger y los stored procedures en FireBird 1.5?.... hace tiempo leí un artículo en este Club donde decía cómo hacerlo, pero lo probé en FireBird 1.5 y no funciona... es error mio o es algo que ya no se puede en FireBird 1.5...

Gracias de antemano

[gendelphi]

Yo siempre lo he hecho asi:

UPDATE RDB$PROCEDURES
SET RDB$PROCEDURE_SOURCE = NULL
WHERE RDB$PROCEDURE_SOURCE IS NOT NULL

Para los SP, y para los Triggers:

UPDATE RDB$TRIGGERS
SET RDB$TRIGGER_SOURCE = NULL
WHERE RDB$TRIGGER_SOURCE IS NOT NULL

y siempre ha funcionado, incluso en Firebird 1.5

Nota: El código (fuente) no se oculta, realmente se elimina.

[teletranx]

Saludos
en los triggers falta, ya que cuando check, falla.

para Triggers
UPDATE RDB$TRIGGERS
SET RDB$TRIGGER_SOURCE = NULL
WHERE Upper( f_blobleft(RDB$TRIGGER_SOURCE,5))<>'CHECK' and RDB$TRIGGER_SOURCE IS NOT NULL

y recuerda que también tienes que borrar la historia

Delete From IBE$VERSION_HISTORY

Saludos

Juan Carlos

[[ArdiIIa]]

Por experiencia, te digo que hay que estar muy seguro de que una BD está muy optimizada y tener un funcionamiento perfecto para realizar esas operaciones, dado que a posteriori y con toda seguridad, esos procedimiento nunca más podrán ser editados.

[lbuelvas]

Bueno, un forista que no he vuelto a ver por estos lados y de quien agradezco mucho sus conocimientos, experiencia y sencilles, el señor "kinobi" elaboro un documento en pdf y un programa para borrar el codigo fuente de procedimientos almacenados que se llama Khidemetadata que pueden encontrar en:

http://homepages.borland.com/torry/tools_dbother.htm

El asunto es que yo modifique un poco las sentencias de actualizacion para no borrar ciertos triggers que utilizo para manejar la auditoria de las base de datos y que pueden ser modificadas por los administradores que hacen uso de mis aplicaciones (por eso necesitan el fuente), es solamente la parte que tiene el texto
AND rdb$trigger_name NOT starting with 'LOG_';
todo lo demas esta intacto a como dijo el señor kinobi y en la documentacion explica el porque de esas sentencias SQL.

Código SQL [-]
update rdb$procedures
set rdb$procedure_source = null
where (rdb$system_flag = 0);

update rdb$triggers
SET rdb$trigger_source = NULL
WHERE (((rdb$system_flag = 0) OR (rdb$system_flag IS NULL))
AND   (rdb$trigger_name NOT IN (SELECT rdb$trigger_name
                                FROM rdb$check_constraints)))
AND   rdb$trigger_name NOT starting with 'LOG_';

update rdb$relations
set rdb$view_source = null
where (rdb$system_flag = 0);

Es posible que se necesite hacer un backup y luego un restore pues en algunas ocasiones reviso la base de datos con IBExpert y veo que no se ha borrado el codigo fuente.

Debido a que hoy dia tiro gran parte de la aplicacion hacia el motor de bases de datos y utilizo Delphi para asuntos netamente de interfase de usuario me veo en la obligacion de borrar el fuente en las bases de datos de los clientes.

Solo quiero hacer una advertencia, siempre hagan copias de seguridad por lo menos de los metadatos antes de cualquier borrado, espero no les pase lo que me paso en estos dias.

Resulta que venia haciendo mis copias de seguridad sin inlcuir ciertas bases de datos, por una extraña razon el 23 de diciembre mi computador se reinicio y empezo Windows XP a hacer una revision del disco algo extraña, con mensajes de indexacion de archivos que no habia visto antes.

Dos de las bases de datos de trabajo quedaron en "0" bytes, es decir se borraron !!!. No tengo copias de seguridad pues por error no estaban en la lista de copias y si voy donde un cliente a sacar una copia de su base de datos ésta tampoco tiene el fuente !!!.

Como les quedo el ojo ? Ocultar los metadatos es buena opcion si quieres proteger tu trabajo intelectual, pero si no es manejado cautelosamente puedes perder meses de trabajo.