Hola a tod@s de nuevo, estoy empezando a crear tablas de BBDD con el CREATE TABLE en lugar de DDS, hasta el momento no he tenido ningún problema, ¡hasta ayer!
Me encuentro con dos casos que sabría resolver pero no me gusta la solución: 1. Cuando creo tablas con SQL le defino dos nombres, uno largo (y descriptivo) para utilizar en SQL y el de sistema para poder utilizarlo con los mandatos CL. Todo bien salvo cuando tengo que hacer un duplicado del objeto en la misma biblioteca, que falla con el error CPF327E – No se permite un nombre alternativo para el archivo XXXXX. ¿Cómo se pueden crear duplicados (CRTDUPOBJ) de ficheros con “nombre alternativo” en una misma biblioteca? 2. Nuestra BBDD tiene más de 20 años y nunca se han utilizado “restricciones referenciales” entre archivos. Ahora quiero utilizarlas, pero no es posible crear dicha tabla si las tablas referenciadas se están utilizando. En un entorno como el nuestro (y seguramente como cualquier otro) donde se utiliza el equipo las 24 horas del día por decenas de usuarios es complicado pararlos a todos para hacer el cambio. ¿Existe alguna forma de crear tablas con restricciones referenciales sin parar al personal? En un entorno tradicional de DDS estos problemas no surgían, puedes duplicar tantas veces como quieras un objeto en la misma biblioteca (cambiando el nombre) y puedes crear tantos archivos como quieras sin molestar al resto de personal. ¿Cómo actuáis en estos casos? Saludos y gracias por vuestros comentarios, Javier Mora De: [email protected] [mailto:[email protected]] En nombre de Javier Mora Enviado el: miércoles, 1 de marzo de 2017 16:48 Para: 'forum.help400' Asunto: RE: Modernización - Transición SQL Gracias Alex. Soy de los que le gusta tener casi todo atado antes de dar un paso de estas dimensiones, pero en muchas ocasiones en muchas ocasiones esa necesidad lo paraliza todo, porque es casi imposible tenerlo todo controlado. Como ya he comentado, he leído mucha documentación sobre el tema. Aunque hay mucha literatura, no encuentro buenos ejemplos a lo que se plantea en estos textos. En muy pocos se concretan decisiones sino que es todo muy generalista. Aun así te ayuda a tener una visión amplia de la situación a la que te enfrentas. (Creo) que tengo muy claro qué hacer para migrar las bases de datos a SQL dejando los programas en RPG sin tocar (ni siquiera recompilar). Es de lo poco concreto que he encontrado. De tus comentarios me llama la atención la gestión de la integridad y de las restricciones, ¿las gestionáis con mandatos o con SQL? Respecto al bloque “optimista” siempre he tenido mis dudas y, desde mi punto de vista, es bastante complicada una solución que detecte cuándo han cambiado los datos leídos y qué datos. Saludos, Javier Mora De: [email protected]<mailto:[email protected]> [mailto:[email protected]] En nombre de Alex Martínez Enviado el: miércoles, 01 de marzo de 2017 15:11 Para: forum.help400 Asunto: Re: Modernización - Transición SQL Intento contestar de forma resumida, porque esto da para una telenovela de varias temporadas.... ;-) La moda de mover aplicaciones a SQL era para aprovechar las ventajas del motor SQE... si las aplicaciones usaban OPNQRYF te quedabas con el motor "tradicional" CQE... hasta que llegó la V7R2 e IBM publicó en un TR varias mejoras para usar el SQE con "cosas" tradicionales.... en fin. Si hay programas en RPG, lo más que puedes tener es una combinación entre DDS y SQL y creo que es la mejor opción (o la única). Hay varios artículos sobre "DDS and SQL - The Winning Combination for DB2 for i" Yo no conozco aplicaciones en RPG en que TODO los accesos a base de datos sean en SQL. Y te hablo de aplicaciones ya migradas a ILE hace 20 años. Si todavía son OPM en tu caso, el primer paso es pasar a ILE. Sobre añadir integridad a tablas: Si ya utilizas ILE, en las operaciones WRITE, UPDATE y DELETE nosotros empezamos a incluir una rutina GetDbErr de gestión de errores de integridad referencial de base de datos, aunque las tablas no tuvieran integridad, pero esto ya dejaba el programa preparado para futuras reglas de integridad. Después al añadir reglas de restricción a la tablas el nombre de cada regla contenía el archivo de mensajes y el id de un error, por ejemplo CHGPFCST FILE(AJUT400/TABLA) CST('AJUTMSGF__AJUT400___ERR0001') Nota: la rutina GetDbErr se basa en unas utilidades de Julian Monypenny de 1997, no recuerdo si se publicaron también en help/400 http://iprodeveloper.com/site-files/iprodeveloper.com/files/archive/iprodeveloper.com/artarchiveimages/predec99/2462-figb.htm El mayor dolor de cabeza es realizar modificaciones de bases de datos con integridad y sobre todo con trigers (a veces se ha disparado un trigger durante un CPYF y se puede liar bien-bien) Sobre el bloqueo pesimista en SQL tal como se hace en RPG hay algo de literatura https://www.itjungle.com/2011/07/20/fhg072011-story02/ En algunos casos el acceso a la BB/DD se externalizado en "APIs" en RPG-ILE para tener un modelo y controlador (MVC) que incluya reglas, validaciones y acceso a tablas. Esto es muy cómodo para luego externalizar como servicio web. me dejo temas sin contestar.... en otro rato seguimos. El 1 de marzo de 2017, 12:41, Javier Mora <[email protected]<mailto:[email protected]>> escribió: Hola a tod@s, desde hace ya bastantes años estoy intentando modernizar nuestra BBDD pero nunca he podido deshacerme de las DDS y empezar a crear los archivos con SQL. Las razones son varias: creo que la más importante es “falta de ganas” y la segunda son los más de 2000 programas que tenemos escritos en OPM RPG y que no queremos “ni tocar”. Esta situación provoca que casi cualquier fichero nuevo o cambiado afecte de alguna manera a bastantes programas RPG antiguos, abortando el intento de modernización de inmediato. Opciones como tipos de datos como VARCHAR, INT, BLOB, el uso de NULOS, etc. no puedan utilizarse si no reconvertimos todos los programas viejos. Desde hace más de ocho años utilizamos SQL incrustado en los nuevos programas, procedimientos almacenados para conexiones JDBC/ODBC, funciones y funciones de tablas de usuario. Pero no terminamos de decidirnos. Mi intención con este correo es recabar las experiencias de los miembros del foro que han dado ya el paso. He leído muchísima documentación (Redbooks, transparencias de conferencias, artículos, etc.) en donde todo se ve muy bonito. Lo que busco son esas cuestiones que no se cuentan pero que suceden en una migración de este tipo. Por ejemplo, yo me he encontrado con varias situaciones por resolver: - Cómo documentar las tablas de la BBDD: nuestra documentación son las DDS, aprovechamos el fuente para añadir los comentarios relacionados con el fichero o con campos concretos. ¿Separo la documentación del fuente que crea la tabla (CREATE TABLE)? ¿La dejo junta? ¿Qué herramientas existen? - Bloqueos de registros: si codifico los nuevos programas con SELECT, INSTERT, UPDATE y DELETE ¿cómo gestiono los bloqueos de registro como lo hace CHAIN? ¿Debo renunciar al bloque por registro? - Integridad referencial: es estupenda pero, ¿qué pasa con esos programas tan antiguos que pueden romper esa integridad? Nos va a tocar revisar los programas o esperar a que fallen para arreglarlos. - CREATE TABLE: ¿cómo establezco valores como el número máximo de registros o reutilizar registros borrados? Esta sentencia SQL no dispone de estas opciones. ¿CHGPF? - ¿Externalizo la E/S con la BBDD? Irán surgiendo muchas más cuestiones. Gracias a todos por vuestra paciencia y vuestras sugerencias. 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.
