Corrijo: no tenemos un miembro fuente por cada restricci�n. Tenemos uno
por fichero, con todas sus restricciones
-----Mensaje original-----
De: Fernando P�rez [mailto:[EMAIL PROTECTED]
Enviado el: martes, 02 de diciembre de 2003 20:44
Para: '[EMAIL PROTECTED]'
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.-----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.
---------------------------
Fernando P�rez.vcf
Description: Binary data
