Buenos días Por darle una vuelta a la solución de Juan Carlos, cuando necesito duplicar una tabla para trabajar con ella y luego al finalizar el proceso ya no la necesito, utilizo:
DECLARE GLOBAL TEMPORARY TABLE ORDERS as (select * from biblioteca.fichero) with data; Esto me crea una tabla ORDERS en QTEMP a imagen de la tabla especificada en la clausula select y con los mismos datos. Al finalizar puedo hacer un DROP TABLE o finalizar el trabajo (está creada en QTEMP). Un saludo > Message: 1 > Date: Wed, 13 Sep 2017 19:25:04 +0200 > From: Juan Carlos Paredes Castañón <juancar...@paredes.info> > Subject: Re: Modernización - Transición SQL > To: "forum.help400" <forum.help400@listas.combios.es> > Message-ID: <8a802caa28c262717f1b84a87a0ba...@paredes.info> > Content-Type: text/plain; charset="utf-8" > > La sentencia CREATE TABLE, tiene también una claúsula LIKE para que tome > la estructura de la tabla que indiques en esta cláusula (tal vez, más > sencillo que crearla con una sub-select de la tabla original). Lo que no > sé, porque no la he utilizado nunca, es si permite el "with data" o > "with no data". Yo suelo hacerlo como te indiqué. > > Una opción que quizá te pueda resultar práctica, si lo haces a menudo, > es crearte un procedimiento almacenado que reciba como parámetros > esquema y tabla de origen y de destino y si debe duplicar datos o no. > Una vez que lo tengas fino, siempre que tengas que hacer un duplicado, > sólo tienes que hacer un CALL a este procedimiento y estarás seguro de > que te va a hacer lo correcto. > > Cambiar de DDS a SQL cuesta un esfuerzo, pero cuando te habitúas a > trabajar con él, la verdad es que es una virguería. > > Saludos y ánimo. > > Juan Carlos > > --- > url: https://www.paredes.info > mail: juancar...@paredes.info > > El 13/09/2017 18:23, Javier Mora escribió: > > > Tengo claro que, como todo cambio, tendremos que hacer un esfuerzo para > readaptarnos a SQL. Muchas de las "costumbres" adquiridas durante más de 20 > años tendremos que dejarlas a un lado, pero mientras descubres y aprendes > la alternativa nos vamos a encontrar con algún "aprieto". > > > > La opción que apunta Juan Carlos para duplicar tablas me puede ser > válida aunque más farragosa que un simple CRTDUPOBJ. El enlace de Alex > también es interesante. > > > > Respecto a los bloqueos al activar la integridad referencial es un > verdadero problema, porque es muy difícil encontrar un hueco en el día > donde las tablas afectadas no estén en uso. Para tablas completamente > nuevas no es un problema. En mi caso, la tabla de artículos es uno de esos > objetos que la utilizan todos los trabajos continuamente. Cualquier > restricción referencial nueva sobre ese archivo será un problema. > > > > Yo, de momento, me he planteado crear la tabla sin restricciones y > activar programas, etc. Cuando haya un hueco, haremos un ALTER TABLE para > activarlas. En este caso nos podremos encontrar con el caso de que los > datos no las cumplan y tendremos que "depurar" la tabla. > > > > Gracias por vuestro interés. > > > > Javier Mora > > > > DE: forum.help400-boun...@listas.combios.es [mailto: > forum.help400-boun...@listas.combios.es] EN NOMBRE DE Alex Martínez > > ENVIADO EL: miércoles, 13 de septiembre de 2017 14:15 > > PARA: forum.help400 > > ASUNTO: Re: Modernización - Transición SQL > > > > Hola > > > > para el primer problema IBM tiene publicado un documento que lo explica, > no sé si te será de ayuda > > http://www-01.ibm.com/support/docview.wss?uid=nas8N1017004 > > > > El problema mucha veces es seguir utilizando mandatos tradicionales como > CRTDUPOBJ,CPYF, etc cuando ya tienes un pie en el mundo SQL. Por ejemplo, > hacer un CRTDUPOBJ duplicando integridad y triggers puede ser una muy mala > idea.... > > > > Y es un problema añadir, quitar o cambiar una restricción si el objeto > está bloqueado, yo todo esto lo controlo antes de empezar a actualizar... > por motivos evidentes. Así que si encuentras la solución... coméntalo por > aquí !!! > > > > El 13 de septiembre de 2017, 13:09, Javier Mora <jm...@musgrave.es> > escribió: > > > > 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: forum.help400-boun...@listas.combios.es [mailto: > forum.help400-boun...@listas.combios.es] 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: forum.help400-boun...@listas.combios.es [mailto: > forum.help400-boun...@listas.combios.es] 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 <jm...@musgrave.es> 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 [1] ) > > Forum.Help400 (c) Publicaciones Help400, S.L. > > > > ____________________________________________________ > > Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd [1] ) > > Forum.Help400 (c) Publicaciones Help400, S.L. > > > > ____________________________________________________ > > Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) > > Forum.Help400 (c) Publicaciones Help400, S.L. > > > Links: > ------ > [1] http://bit.ly/db68dd > ------------ próxima parte ------------ > Se ha borrado un adjunto en formato HTML... > URL: < > http://listas.combios.es/cgi-bin/mailman/private/forum.help400/attachments/20170913/4ed40b15/attachment-0001.html > > > > ------------------------------ > > __________________________________________________ > Forum.HELP400 es un servicio m&amp;#225;s de ServerNEWS. > &amp;#169; Publicaciones Help400, S.L. - Todos los derechos reservados > http://www.help400.es > _____________________________________________________ > > Para darte de baja visita la siguente URL: > http://listas.combios.es/mailman/listinfo/forum.help400 > > Fin de Resumen de Forum.help400, Vol 131, Envío 15 > ************************************************** >
____________________________________________________ Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd ) Forum.Help400 © Publicaciones Help400, S.L.
