FTP | CCD | Buscar | Trucos | Trabajo | Foros |
|
Registrarse | FAQ | Miembros | Calendario | Guía de estilo | Temas de Hoy |
|
Herramientas | Buscar en Tema | Desplegado |
#1
|
|||
|
|||
Consecuencias de la proteccion en FireBird
Saludos
Hace algún tiempo estoy protegiendo los sp y los triggers de FireBird Con Para SP UPDATE RDB$PROCEDURES SET RDB$PROCEDURE_SOURCE = NULL WHERE RDB$PROCEDURE_SOURCE IS NOT NULL 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 Hace más de un año baje un software español, en el cual trabajaban con Delphi e InterBase V6.0, el cual solamente los sp estaban protegidos. Más adelante buscando un método para proteger lo almacenado en Internase (sp, triggers), llegue a esta variación que actualmente la utilizo con FireBird 1.5.1 Mis preguntas son las siguientes: ¿Que consecuencias tiene proteger los Triggers? Por mi parte he protegido primero InterBase y posteriormente FireBird, y no he encontrado problema. Se preguntarán por que mi pregunta, ya que la estoy instalando a un cliente (Empresa), he observado cosas peculiares, pero eso puede ser problema de su red, ya que la misma aplicación no funciona bien en su PC, pero en mío si., la volví a copiar y funciona bien. Posteriormente observando los triggers asociados a las distintas tablas, no fueron encontrados, pero estaban, y funcionaban A veces me da la sensación de que estoy trabajando con otras versiones, tanto FireBird como la Aplicación. La única diferencia es que una esta protegida y la otra no ¿A quien le ha pasado esto? Si lo soluciono, ¿Cómo lo hizo? Juan Carlos Última edición por teletranx fecha: 05-10-2004 a las 00:51:56. |
|
|
|