Gracias Alex. De momento veo todo esto muy complicado y necesito estudiar con tranquilidad la cuestión del registro por diario y control de compromiso. Si desactivo las restricciones de integridad todo funciona como si no estuvieran y eso me da un margen.
Crear receptores y diarios creo que lo tengo claro, pero qué estrategia utilizas: ¿biblioteca separada o en la misma donde se ubican las tablas? Me asusta un poco el efecto que puede tener el registro por diario en el resto de programas antiguos que pudieran necesitar el nuevo fichero, sobre todo porque ahora no puede dedicarme a realizar las adaptaciones que fueran necesarias. Ya plantearé más dudas. Buen fin de semana a todos. De: [email protected] [mailto:[email protected]] En nombre de Alex Martínez Enviado el: viernes, 24 de noviembre de 2017 13:56 Para: forum.help400 Asunto: Re: Modernización - Transición SQL Hola te contesto brevemente En general es muy recomendable registrar la tablas por diario, sobre todo en el "mundo SQL" y es bastante sencillo, no veo motivo para no hacerlo, solo hay que crear un receptor y el diario, aunque se hace automáticamente cuando creas una biblioteca con CREATE COLLECTION y luego según vas creando las tablas Sobre el crecimiento si indicas en el journal que los receptores sean gestionados por *SYSTEM con el parámetro MNGRCV y con DLTRCV que los borre con *YES en mi caso tengo añadidas reglas de integridad desde mucho antes y desde el mundo DDS con ADDPFCST !!! Tendrás que usar commit y rollback en los programas según el tipo de reglas.... Sí que necesitas control de compromiso si usas reglas de integridad de comprobación que impidan un operación de grabación de datos, por ejemplo Pero no lo necesitarás para una regla de clave primaria o de clave única Para una de restricción referencial si que necesitas journal si la regla es borrar en cascada (esto lo tendría que comprobar) El 24 de noviembre de 2017, 9:52, Javier Mora <[email protected]<mailto:[email protected]>> escribió: Hola a tod@s, como ya he comentado en este mismo “hilo”, estoy utilizando SQL (en lugar de DDS) en pequeños proyectos para crear tablas y vistas. Quiero aprovechar las restricciones de integridad referencial para mejorar y controlar la consistencia de la BBDD. Sin embargo, es con este mecanismo con el que me estoy encontrando con más problemas. Ya he descubierto que para activar estas restricciones el sistema utiliza un bloque exclusivo sobre las tablas afectadas, lo que me obliga a hacer los cambios en horarios fuera de trabajo o buscar un hueco en el día donde afecte al menor número de usuarios posible. Ahora me encuentro con otro problema. Resulta que todas las tablas referenciadas necesitan estar registradas por diario, si no es imposible actualizar o borrar registros. No tenía previsto utilizar registro por diario, sobre todo porque no domino el tema. Así que estas son mis dudas: 1. ¿Es obligatorio registrar por diario las tablas con restricciones de integridad referencial? 2. ¿Se puede evitar de alguna forma el uso del diario sin perder el control de las restricciones? 3. ¿El registro por diario me obliga a utilizar el control de compromiso en todos mis programas? 4. ¿O sólo lo utiliza el motor de base de datos cuando lo necesite? 5. Recomendaciones, según vuestra experiencia, de donde ubicar diario y receptores (yo apunta en la misma biblioteca de los ficheros). 6. ¿Qué precauciones debo tener con el uso del registro por diario? Por ejemplo, crecimiento de los receptores. Si veo que no le “saco punta” a este tema pronto tendré que desistir (de momento) en el tema de las restricciones. Un saludo y gracias por vuestros comentarios. Javier Mora ____________________________________________________ Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 © Publicaciones Help400, S.L.
____________________________________________________ Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 © Publicaciones Help400, S.L.
