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: [email protected]
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: [email protected]
> [mailto:[email protected]] 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 <[email protected]> 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: [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]] 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]> 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____________________________________________________
Únete a Recursos AS400, nuestra Comunidad ( http://bit.ly/db68dd )
Forum.Help400 © Publicaciones Help400, S.L.
