subject:"RE\: Modernización \- Transición SQL"

RE: Modernización - Transición SQL

2017-11-24 Por tema Javier Mora

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: forum.help400-boun...@listas.combios.es 
[mailto:forum.help400-boun...@listas.combios.es] 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 
<jm...@musgrave.es<mailto:jm...@musgrave.es>> 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.

Re: Modernización - Transición SQL

2017-11-24 Por tema Alex Martínez

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  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.

RE: Newsletter RE: Modernización - Transición SQL

2017-11-24 Por tema Javier Mora

Yo sólo he probado con SQL o con DFU, todavía no he probado desde programa RPG 
con CHAIN/UPDATE.

Los programa RPG con SQL los compilo todos con COMMIT(*NONE), pero no tengo 
nada claro en qué me afectarán el registro por diario.

Gracias Alberto

De: forum.help400-boun...@listas.combios.es 
[mailto:forum.help400-boun...@listas.combios.es] En nombre de alberto
Enviado el: viernes, 24 de noviembre de 2017 11:04
Para: forum.help400
Asunto: Re: ** Newsletter ** RE: Modernización - Transición SQL

Hola Javier.
No sé si es el caso de las tablas con restricción de integridad referencial, 
pero con tablas 'normales' que no estén registradas por diario, si quieres 
borrar o actualizar, tienes que compliar el programa con la opción
 COMMIT *NONE.
Salu2.



De:"Javier Mora" <jm...@musgrave.es<mailto:jm...@musgrave.es>>
Para:"forum.help400" 
<forum.help400@listas.combios.es<mailto:forum.help400@listas.combios.es>>
Fecha:24/11/2017 10:14
Asunto:    ** Newsletter ** RE: Modernización - Transición SQL
Enviado por:
forum.help400-boun...@listas.combios.es<mailto:forum.help400-boun...@listas.combios.es>




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.

Re: Newsletter RE: Modernización - Transición SQL

2017-11-24 Por tema alberto

Ah, me he dejado una cosa. Yo personalmente tengo una sóla biblioteca en 
la que guardo todos los journals.
Salu2



De: alberto/arcadie
Para:   "forum.help400" <forum.help400@listas.combios.es>
Fecha:  24/11/2017 11:04
Asunto: Re: ** Newsletter ** RE: Modernización - Transición SQL
Enviado por:Alberto Martinez


Hola Javier.
No sé si es el caso de las tablas con restricción de integridad 
referencial, pero con tablas 'normales' que no estén registradas por 
diario, si quieres borrar o actualizar, tienes que compliar el programa 
con la opción
 COMMIT *NONE. 
Salu2.




De: "Javier Mora" <jm...@musgrave.es>
Para:   "forum.help400" <forum.help400@listas.combios.es>
Fecha:  24/11/2017 10:14
Asunto: ** Newsletter ** RE: Modernización - Transición SQL
Enviado por:forum.help400-boun...@listas.combios.es



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.

Re: Newsletter RE: Modernización - Transición SQL

2017-11-24 Por tema alberto

Hola Javier.
No sé si es el caso de las tablas con restricción de integridad 
referencial, pero con tablas 'normales' que no estén registradas por 
diario, si quieres borrar o actualizar, tienes que compliar el programa 
con la opción
 COMMIT *NONE. 
Salu2.



De: "Javier Mora" <jm...@musgrave.es>
Para:   "forum.help400" <forum.help400@listas.combios.es>
Fecha:  24/11/2017 10:14
Asunto: ** Newsletter ** RE: Modernización - Transición SQL
Enviado por:forum.help400-boun...@listas.combios.es



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.

RE: Modernización - Transición SQL

2017-11-24 Por tema Javier Mora

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.

Re: Modernización - Transición SQL

2017-09-15 Por tema Jose Luis Hernandez Riesgo

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 u

Re: Modernización - Transición SQL

2017-09-13 Por tema Juan Carlos Paredes Castañón

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 X. 
> 
> ¿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

RE: Modernización - Transición SQL

2017-09-13 Por tema Javier Mora

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<mailto: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 X.

¿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>

[mailto: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 du

Re: Modernización - Transición SQL

2017-09-13 Por tema Juan Carlos Paredes Castañón

Para el primer error, mi solución sería crear la nueva tabla a través de
SQL también: 

Create Table Destino.Mi_Nombre_Largo_B as (Select * from
Origen.Mi_Nombre_Largo_A) 

Y añadir la cláusula "with Data" (si quieres que se dupliquen los
registros) o "with No Data" (si sólo quieres duplicar la estructura).  

Respecto a la segunda, no puedo ayudarte. No he trabajado nunca con
integridad referencial

---
url: https://www.paredes.info
mail: juancar...@paredes.info 

El 13/09/2017 13:09, Javier Mora 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 X. 
> 
> ¿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. 
> 
> S

Re: Modernización - Transición SQL

2017-09-13 Por tema Alex Martínez

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 X.
>
> ¿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
> <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

RE: Modernización - Transición SQL

2017-09-13 Por tema Javier Mora

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 X.

¿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>
 [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

RE: Modernización - Transición SQL

2017-03-01 Por tema Javier Mora

Cierto, pero otra técnica para evitarlo es definirse un lógico con el mismo
nombre y estructura que el físico original. Los programas que no se cambien
seguirán trabajando sin problemas.

Gracias Fernando.

De: forum.help400-boun...@listas.combios.es
[mailto:forum.help400-boun...@listas.combios.es] En nombre de FERNANDO MURU
ADURIZ
Enviado el: miércoles, 01 de marzo de 2017 17:18
Para: forum.help400
Asunto: RE: Modernización - Transición SQL

Hola,

Al hilo de lo comentado, ten en cuenta que si regeneras las tablas, en nivel de
versión cambia, y los programas viejos pueden protestar. La alternativa es
ponerles LVLCHK(*NO) … [CHGPF una vez más].

Saludos,
F.Muru

De:
forum.help400-boun...@listas.combios.es<mailto: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.

(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>
[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<mailto: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 2

RE: Modernización - Transición SQL

2017-03-01 Por tema FERNANDO MURU ADURIZ

Hola,

Saludos,
F.Muru

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.

(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

Intento contestar de forma resumida, porque esto da para una telenovela de
varias temporadas ;-)

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/

me dejo temas sin contestar en otro rato seguimos.

El 1 de marzo de 2017, 12:41, Javier Mora
<jm...@musgrave.es<mailto:jm...@musgrave.es>> escribió:
Hola a tod@s,

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 al

RE: Modernización - Transición SQL

2017-03-01 Por tema Javier Mora

Gracias Alex.

(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 ;-)

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/

me dejo temas sin contestar en otro rato seguimos.

El 1 de marzo de 2017, 12:41, Javier Mora
<jm...@musgrave.es<mailto:jm...@musgrave.es>> escribió:
Hola a tod@s,

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 res

Re: Modernización - Transición SQL

2017-03-01 Por tema Alex Martínez

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  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

RE: Modernización - Transición SQL

Re: Modernización - Transición SQL

RE: Newsletter RE: Modernización - Transición SQL

Re: Newsletter RE: Modernización - Transición SQL

Re: Newsletter RE: Modernización - Transición SQL

RE: Modernización - Transición SQL

Re: Modernización - Transición SQL

Re: Modernización - Transición SQL

RE: Modernización - Transición SQL

Re: Modernización - Transición SQL

Re: Modernización - Transición SQL

RE: Modernización - Transición SQL

RE: Modernización - Transición SQL

RE: Modernización - Transición SQL

RE: Modernización - Transición SQL

Re: Modernización - Transición SQL

16 matches

Site Navigation

Mail list logo

Footer information