Hola. Pues yo me decanto por el LVLCHK(*NO), de hecho tenemos por norma que si compramos una aplicación a un proveedor externo y no compramos los fuentes :-(, entonces obligamos a que todos los programas estén compilados con LVLCHK(*NO), pues así podemos hacer "ampliaciones" a la B.D. sin tener que volver a pedir al proveedor que nos recompile toda la aplicación.
Incluso si tenemos los fuentes, por defecto siempre compilamos con LVLCHK(*NO), ya que desde mi punto de vista el LVLCHK(*NO) es la mejor opción. De hecho si utilizasemos SQL no habría el problema del LVLCHK, pues el SQL es dinamico y cada vez que ataca a la B.D. se construye la sentencia con TODOS los campos que existen en ese momento (incluidos los añadidos posteriormente a la compilación). Esta potencia de control de Registros no la tiene el RPG (o el COBOL) utilizando el Acceso a la B.D. de modo directo, y para paliarla se creó el LVLCHK(*NO), está opción permite seguir ejecutando un programa aunque se haya retocado la B.D. para ampliar los Ficheros, no es exactamente lo mismo que el SQL (pues no reconstruye dinamicamente los campos del fichero), pero permite utilizar un registros de un fichero con más longitud que la que había en el momento de la compilación del programa. Solo hemos detectado 3 problemas con esta opción, y todas son por mal uso (o falta de conocimiento según se mire) de la opción del LVLCHK(*NO), estas son: 1º) Ampliación de la Longitud de un Campo, o cambiar el Tipo de Campo (p.e. de Alfanuemrico a numérico empaquetado), esto produce que se desplazen las posiciones del resto de los campos, lo que provoca que los programas no recompilados de nuevo graben en posiciones erroneas. 2º) Intercalado de Campos entre medio de otros, o simplemente cambio del orden de los campos previos, esto produce el mismo efecto que el punto 1º) 3º) Adicción de Campos numericos al final del Fichero, si estos campos se crean en modo empaquetado o binario, entonces dan problemas, pues los programas que graban (WRITE/UPDATE) en el Fichero entienden SIEMPRE que estos campos añadidos son alfanuméricos, y siempre los inicializan con Blancos, lo que puede provocar errores de Correlación de Campos (p.e. el QRY puede llegar a NO leer los registros), pero no dan problemas a nivel de programa, si estos previamente se han compilan con otra de las opciones, la de ignorar error de datos decimales: IGNERRDEC(*YES) en RPG III, o FIXNBR(*ZONED) en RPG IV. Esto demuestra que SI no se tocan los campos anteriores para nada, y solo se añaden nuevos campos al final de los existentes, entonces NO hay problemas. Nota: Lo único que hay que tener muy en cuenta es el punto 3º) de nunca añadir un campo Numérico empaquetado o Binario, y si se necesita añadirlo, entonces en este caso SIEMPRE es aconsejable compilar los programas que hacen WRITE/UPDATE (pero no es necesario compilar todos los progamas que utilizan el Fichero). Siguiende estas normas de uso (que son complementarias a las indicadas por Javier Mora) no hay ningún problema, y se flexibiliza una barbaridad cualquier actualización de la B.D. sin tener que reconstruir completamente toda la Aplicación. Salu2. Cid Fernández Sangrador e-correo:[EMAIL PROTECTED] En informática no hay nada imposible... solo es cuestión de tiempo. -----Mensaje original----- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] En nombre de Javier Mora Enviado el: lunes, 29 de agosto de 2005 15:55 Para: [email protected] Asunto: RE: Comprobacion a nivel formato de registro Hola a todos: Aunque estoy de acuerdo que con LVLCHK(*YES) se evitan muchos problemas, en mi implantación no usamos casi nunca este sistema. Por normas internas siempre seguimos en el departamento esto pasos: 1. Añadir al final del registro los campos nuevos. 2. Modificar todos los programas que inserten registros nuevos inicializando estos campos correctamente. 3. Poner en el físico y lógicos LVLCHK(*NO). 4. Realizar el cambio del fichero y compilar programas de una sola vez. Nuestras aplicaciones están formadas por cientos de programas que usan de algún modo los ficheros. Como no tenemos una herramienta que compile automáticamente los programas, usamos este método. También surge un pequeño problema: nosotros llevamos un control sobre el uso de programas y fechas de última modificación. Una compilación (sin haber modificado una sola línea fuente) inicializa estos valores. Este método lo uso desde que tengo conciencia sobre este tema y, creo, fui ensañado por profesionales que sabían lo que hacían. Lo llevo aplicando durante más de 10 años y he tenido muy pocos problemas. Lo cierto que estos pasos _tienen_ que ser sistemáticos sino SEGURO QUE HABRAN INCIDENCIAS GRAVES. Yo me decanto por un punto intermedio (que me gustaría aplicar siempre) entre ambas visiones. Usaría el método aquí explicado para el ininico de los cambios; luego realizaría una compilación masiva del resto de programas (puede llevar tiempo) y finalmente devolvería LVLCHK(*NO). Un saludo, Javier Mora Dpto. Informática Dialsur S.A.U. > -----Mensaje original----- > De: Establiments Vidal [SMTP:[EMAIL PROTECTED] > Enviado el: lunes, 29 de agosto de 2005 10:26 > Para: [email protected] > Asunto: Comprobacion a nivel formato de registro > > Hola a todos: > > Nosotros cuando queremos añadir un campo a una base de datos > utilizamos el CHGPF con el valor por defecto LVLCHK(*YES) y despues > compilamos los programas correspondientes , aunque ya sabemos que > utilizando LVLCHK(*NO) no es necesario compilar los programas , ¿esto > puede dar algun problema ? > ¿Cual es la politica correcta ? . ¿ Crear todas la bases de datos CRTPF > con LVLCHK(*NO), i CHGPF LVLCHK(*NO)? ¿ Que opinais? > > Gracias a todos. > > __________________________________________________ > Forum.HELP400 es un servicio más de NEWS/400. > © Publicaciones Help400, S.L. - Todos los derechos reservados > http://www.help400.es > _____________________________________________________ > > Para darte de baja visita la siguente URL: > http://coyote.combios.es/mailman/listinfo/forum.help400 __________________________________________________ Forum.HELP400 es un servicio más de NEWS/400. © Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja visita la siguente URL: http://coyote.combios.es/mailman/listinfo/forum.help400 __________________________________________________ Forum.HELP400 es un servicio más de NEWS/400. © Publicaciones Help400, S.L. - Todos los derechos reservados http://www.help400.es _____________________________________________________ Para darte de baja visita la siguente URL: http://coyote.combios.es/mailman/listinfo/forum.help400
