Hola:
Pues como dec�a en otro mail con respecto a base de datos
nosotros tenemos un problema que no hemos podido solucionar:
Resulta que tenemos una aplicaci�n cuyas CL's hacen un OVRDBF de los ficheros con SHARE(*YES) y luego hacen un OPNDBF con OPTION(*ALL). En la cadena, en algunos programas, se intenta abrir el fichero con la opci�n input. Estas cadenas funcionan perfectamente sin ning�n error hasta que a�adimos un Trigger en alguno de los ficheros, a partir de aqu� comienzan a dar el error de control de compromiso CPF4293.
Me he dado cuenta que el funcionamiento de un trigger de sistema (l�ase trigger a partir de RPG) y un trigger SQL (creaci�n a partir de SQL) no es el mismo. El de sistema no casca en la situaci�n comentada.
-----Mensaje original-----
De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]En nombre de Fernando P�rez
Enviado el: mi�rcoles, 03 de diciembre de 2003 11:01 a.m.
Para: '[EMAIL PROTECTED]'
Asunto: RE: Integridad Referencial.Bueno, por vuestra experiencia parece que lo de copiar tablas no es demasiado problema ( ya te digo, nosotros estamos empezando con este tema ). De todas maneras, y ya entrando en el terreno de lo opinable, a mi me sigue sin gustar el tener toda la definici�n de la tabla con sus restricciones y dem�s en un solo miembro fuente. Eso significa no poder crear desde los fuentes sql la base de datos o parte de ella, o en el mejor de los casos no sin tener extremo cuidado en el orden de generaci�n de las tablas.No lo comento por llevar la contraria ni porque est� convencido de que nuestro m�todo sea mejor. Es para ver si la gente se anima y van contando sus experiencias en el tema ;-)-----Mensaje original-----
De: Santiago G Mart� [mailto:[EMAIL PROTECTED]
Enviado el: mi�rcoles, 03 de diciembre de 2003 9:37
Para: [EMAIL PROTECTED]
Asunto: RE: Integridad Referencial.
Hola Fernando:
Efectivamente me refer�a a OPERATIVO, perdona la confusi�n.
El trigger se crea como trigger SQL en la misma biblioteca que el fichero, y es el propio sistema el que le da el nombre.
Lo que ocurre es que si duplicas el fichero en otra biblioteca, autom�ticamente se duplican los triggers en la nueva biblioteca, pero quedan INOPERATIVOS y no te dejan hacer nada con el fichero.
La �nica soluci�n que hemos encontrado es eliminarlos y volverlos a crear, desde el mismo fuente, con lo cual se crean OPERATIVOS.
Parece ser que aunque en las sentencias del trigger NO calificamos los ficheros con el nombre de biblioteca, el trigger se guarda la lista de bibliotecas necesarias para su ejecuci�n en un atributo llamado SQLPATH.
Cuando copiamos el trigger a la nueva biblioteca, podemos ver que en el SQLPATH est� la vieja biblioteca, y no la nueva, y �sta es la raz�n de que est� inoperativo, ya que �l supone que no va a funcionar bien, ya que el propio fichero est� en una biblioteca que no tiene en el SQLPATH.
Supongo que si hubiera una forma de cambiarle el SQLPATH podr�a funcionar sin problemas.
Nosotros, toda la informaci�n referida a un fichero la almacenamos en un solo fuente, a efectos de documentaci�n, y movemos los ficheros de biblioteca por copia, con o sin datos, sin ning�n problema.
Bueno, alg�n que otro quebradero de cabeza, ya que si te pasas un fichero HIJO (con dependencia FOREIGN KEY a un fichero PADRE) a otra biblioteca donde no existe el PADRE, la restricci�n FK del HIJO cambia y apunta a un fichero PADRE, de la nueva Biblioteca, que como ya he dicho no existe.
Puedes trabajar con el fichero HIJO sin problemas hasta que realices una operaci�n que cause una comprobaci�n de restricci�n imposible de realizar, como por ejemplo a�adir un registro. En ese momento el fichero HIJO pasa a tener una Restricci�n en estado "Pendiente de Comprobar", y ya no te deja hacer ni un m�sero CHAIN o SELECT, aunque puedes seguir a�adiendo registros.
Naturalmente, todo vuelve a la normalidad cuando copias el fichero PADRE a la nueva Biblioteca, siempre y cuando, ninguno de los registros a�adidos violen la restricci�n FK con el fichero PADRE.
Bueno, perdona por el rollo, pero creo que es un punto interesante.
Lo bueno es que habilitando y deshabilitando restricciones y haciendo consultas puedes resolver todos los problemas, menos los de los TRIGGERS, que se copian a la nueva biblioteca y quedan INOPERATIVOS y no hay m�s... mandatos, que borrarlos y volverlos a crear.
Saludos,
---------------------------
Santiago Mart�
Dusen, S.A.
---------------------------
Fernando P�rez <[EMAIL PROTECTED]>
Enviado por: [EMAIL PROTECTED]02/12/2003 20:44
Por favor, responda a forum.help400
Para: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Asunto: RE: Integridad Referencial.
Creo que te refieres a lo que el Op's Navigator llama como 'operativo'. Creo que esta propiedad no tiene que ver con si est� activado (*enabled) o no el trigger, y parece que se refiera m�s bien a posibles problemas a la hora de ejecutar este trigger ( quiz�s al ser de otra biblioteca se ve afectado por la lista de bibliotecas, o algo as�).
Una pregunta: �El trigger se crea en la misma biblioteca que la tabla?
Intenta crear uno de esos triggers en la biblioteca de pruebas, elimin�ndolo previamente, a ver si as� se te queda operativo.
En cuanto a c�mo copiar las tablas a bibliotecas de pruebas, nosotros tenemos un miembro fuente para la definici�n de cada tabla, otro para la definici�n de cada una de las restricciones referenciales, otro para la definici�n de cada trigger , otro para cada �ndice ...
De esta manera, a la hora de pasar x tablas de una biblioteca a otra, har�amos ( digo 'har�amos' porque tambi�n estamos empezando y a�n no hemos hecho pasos masivos de tablas para probar ) primero los runsqlstm de los fuentes que crean las tablas. A continuaci�n, CPYF'S desde las originales para cargarlas, y a continuaci�n los runsqlstm's de las restricciones referenciales, triggers y dem�s ( si copias datos con restricciones referenciales activas va a ser un infierno, ya que tienes que ir cargando las tablas en el orden correcto para no incumplir la integridad referencial. Aunque tambi�n puedes inhabilitarla temporalmente para copiar los datos y luego volverla a habilitar, pero veo m�s pr�ctico crearla tras copiar todos los datos).
Espero que algo de lo dicho te sirva.Saludos.
Fernando P�rez.
Cer�mica Saloni. Dpto. Sistemas
-----Mensaje original-----
De: Santiago G Mart� [mailto:[EMAIL PROTECTED]
Enviado el: martes, 02 de diciembre de 2003 20:00
Para: [EMAIL PROTECTED]
Asunto: RE: Integridad Referencial.
Debe ser un problema de mis pruebas, Vicente, pero yo tengo una tabla con el trigger *ENABLED e INACTIVO, y tantas veces como cambio el estado de ENABLED a DISABLED y viceversa, el trigger sigue inactivo.
He de aclarar que es un trigger SQL, no un programa externo.
Saludos,
---------------------------
Santiago Mart�
Dusen, S.A.
---------------------------
Vicente Garc�a <[EMAIL PROTECTED]>
Enviado por: [EMAIL PROTECTED]02/12/2003 19:51
Por favor, responda a forum.help400
Para: "'[EMAIL PROTECTED]'" <[EMAIL PROTECTED]>
cc:
Asunto: RE: Integridad Referencial.
Buenas tardes:
Nosotros tambi�n estamos con replanteamientos de este tipo. Otra de las sorpresas que nos encontramos con la integridad referencial, es que si el registro de una tabla padre est� bloqueado por un programa A, y se intenta p.e. a�adir un registro a una tabla hijo que debe comprobar la restricci�n contra el padre desde un programa B, el programa B da un error de que no se ha podido comprobar las restricci�n. En un principio pensamos que era por no tener tiempo de espera el registro (WAITRCD de CHGPF). A este valor siempre le hemos dado valor de *NOMAX, para en el caso de que se produjera un intento de acceso desde dos procesos al mismo registro para actualizarlo no hubiera 'petadas' y uno de los trabajos se quedara esperando. Este valor no parece afectar a la CST y la comprobaci�n es inmediata. Para solventar el problema no vemos otra soluci�n que monitorizar las lecturas y si se produce un error de este tipo, volverla a reintentar, asi sucesivamente. Esta soluci�n supone un extra de esfuerzo en la programaci�n que todav�a no hemos decidido.
Ser�a interesante que alguine con mas experiencia aportara su opini�n al respecto.
Respecto al activar los triggers con el mandato CHGPFTRG y el par�metro STATE(*ENABLED) se puede activar.
Saludos
-----Mensaje original-----
De: Santiago G Mart� [mailto:[EMAIL PROTECTED]
Enviado el: martes, 02 de diciembre de 2003 19:40
Para: [EMAIL PROTECTED]
Asunto: Integridad Referencial.
Hola a todos.
Despu�s de una eternidad trabajando con el AS/400, finalmente nos hemos decidido a definir los ficheros f�sicos con SQL y pasar de las DDS.
Tambi�n estamos aplicando exhaustivamente la Integridad Referencial y los Triggers.
Nos estamos encontrando con sorpresas, que una vez analizadas parecen razonables, pero que debido a nuestros h�bitos de trabajo nos complican la vida.
Ahora las preguntas:
- �Tiene alguien experiencia trabajando con integridad referencial?
- Cuando duplicas un fichero en una biblioteca de pruebas, se copian los Triggers, pero quedan inhabilitados. �C�mo se habilitan?
-�Se puede cambiar el SQLPATH de un trigger?
-�Qu� metodolog�a emple�is cuando necesitas copiar un grupo de tablas a una biblioteca para pruebas o modificaciones?
Se agradecen todo tipo de comentarios y sugerencias.
Saludos,
---------------------------
Santiago Mart�
Dusen, S.A.
---------------------------
