Bienvenidos a Iseries Venezuela

Las mejores prácticas, recursos, tips, enlaces, videos y artículos para informáticos relacionados con el Iseries y el As/400 lenguajes de programación RPG, ILE RPG y SQL.

The best practices, resources, tips, links, videoes and articles for computer related to the Iseries and the As/400 languages of programming RPG, ILE RPG and SQL.

martes, 28 de diciembre de 2010

Bitácoras.



                         









En algunas organizaciones se requieren aplicaciones que sirvan de bitácora para que el usuario pueda plasmar en ellas comentarios, opiniones y seguimientos que no siempre son posibles de estandarizar. Por ejemplo, en una clínica, las descripciones de las dolencias no pueden estandarizarse puesto que depende de la edad del paciente, el historial médico y las complicaciones previstas e imprevistas que conforman un cuadro médico único e imposible de codificar en términos computacionales. En estos casos, podemos proveer alguna aplicación sencilla en el AS/400 que además de guardar el responsable del registro de la bitácora, la fecha y hora de registro y el texto descriptivo del cuadro médico o de la situación emergente que se está describiendo, podemos incluir algunos campos a manera de cuestionario para asegurarnos de que el usuario cargue información significativa que permita a cualquier supervisor de la organización tener una idea mas clara de lo que sucede con el caso en seguimiento.

Un ejemplo de esto podría se la inclusión de campos como:
Días adicionales en la clínica.
Monto adicional por día de estadía.
Cambio de dieta. (si o no)
Cambio de tratamiento.(si o no)
Cambio de enfermera (si o no)
Tratamientos adicionales (Si o no).

Estas y otras preguntas tipo cuestionario corto, pueden dar una información resumida de los aspectos relevantes en relación al paciente aún cuando el texto descriptivo contenga términos médicos o abreviaturas que aunque para el médico son vitales, para otras áreas administrativas de la organización que realizan seguimiento del caso puede resultar engorroso y de poca utilidad operativa. La idea además de cubrir un requerimiento no estandarizable, es asegurarnos de que el usuario información significativa para la organización entera que operativamente funciona como un todo integrado que recibe y envía información continuamente.

Este ejemplo es exportable para cualquier otro tipo de organización que requiere llevar bitácoras en línea con información no estándar ni codificable desde el punto de vista informático.


Autor: Ing. Liliana Suárez.


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.

jueves, 16 de diciembre de 2010

SQL y el JOIN



                        






En el manejo del SQL el empleo del JOIN es muy importante para realizar búsquedas en la base de datos y sobretodo para comprobar la integridad de la data.
Existen tres tipos de JOIN: INNER JOIN, LEFT JOIN, RIGHT JOIN.
Vamos a ver con un ejemplo como funcionan estos JOIN.

Supongamos que tenemos dos bases de datos:

La base de datos EMPLEADOS que contiene la siguiente información.
Clave = Id, Nacionalidad

Id. 5886825
Nombre= Pedro Perez
Nacionalidad = USA

Id. 66677889
Nombre = Juan Rodríguez
Nacionalidad = MEX

La base de Datos SUELDOS que contiene la siguiente información:
Clave = ID, NACIONALIDAD, DEPARTAMENTO

Id. 5886825
Nacionalidad = USA
Sueldo = 5000,00
Departamento = Contabilidad.

Id. 444333221
Nacionalidad = BOL
Sueldo = 8000,00
Departamento = Finanzas


En este momento Juan Rodríguez no ha sido asignado a ningún departamento.

La denominación Archivo1 se lo asignamos a la Base de Datos  EMPLEADOS
La denominación Archivo2 se lo asignamos a la base de Datos SUELDOS


Vamos a ver cual es el resultado de la consulta cuando trabajamos con INNER JOIN:


SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO INNER JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

El resultado de la búsqueda es:

5.886.825, 5.886.825, Pedro Perez. 5000

Esto corresponde en la imagen al área de color amarillo de la figura, donde están los empleados que se encuentran en ambas bases de datos.


Vamos a ver cual es el resultado de la consulta cuando trabajamos con LEFT JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO LEFT JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

66.677.889, NULL, Juan Rodríguez. NULL

Esto corresponde en la imagen al área de color azul de la figura, donde están los empleados que se encuentran SOLO en la base de datos: EMPLEADOS.


Vamos a ver cual es el resultado de la consulta cuando trabajamos con RIGHT JOIN:

SELECT Archivo1.ID, Archivo2.ID, Archivo1.NOMBRE, Archivo2.SUELDO RIGHT JOIN SUELDOS Archivo2 ON  Archivo1.ID = Archivo2.ID and Archivo1.NACIONALIDAD = Archivo2.NACIONALIDAD.

NULL, 444333221, NULL, 8000

Esto corresponde en la imagen al área de color verde de la figura, donde están los empleados que se encuentran SOLO en la base de datos: SUELDOS. Este último resultado nos está señalando que no hay integridad en la Base de Datos y debemos revisar que está ocurriendo.



Autor: Ing. Liliana Suárez.


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.



jueves, 2 de diciembre de 2010

Haciendo Fácil lo Difícil











Una estrategia de programación muy vieja pero muy buena.

Cuando realizamos programas de actualización que permiten ingresar, modificar y eliminar información, podemos vernos atrapados en lazos dentro de lazos dentro de lazos. Siguiendo el Estándar de IBM en el manejo de las teclas de función, usamos el  F3 para salir y F12 para regresar a la pantalla anterior, (en todas las pantallas) y para navegar de una pantalla a otra dentro del programa hacemos While que a su vez tienen internamente otros While que tienen otros While, etc. Todos estos while finalizan por la misma condición *in03 o también *in12.

Si utilizamos un CASE como el MAIN del programa, se nos facilita el proceso. Este CASE  según el nivel de ejecución (mas interno o mas externo) direcciona a la rutina ha ser ejecutada sin necesidad de tener lazos anidados.

Algoritmo de Ejemplo.

                     NIVEL = 1
                     DOW NIVEL <> 0
                       CASE
                        NIVEL = 1      EXSR pantalla1
                        NIVEL = 2      EXSR pantalla 2
                       ENDCAS
                     ENDDO
                    *INLR = *ON

BEGSR PANTALLA1
Muestra pantalla1
Valida pantalla1
Si F12 or F3 entonces Nivel = 0
Sino
   Si no hay error nivel = 2
   Fin-SI
  Fin_SI
ENDSR

BEGSR PANTALLA2
Muestra pantalla2
Valida pantalla2
Si F12 entonces Nivel = 1
Sino
Si F3 entonces Nivel = 0
 Sino
   Si no hay error Procesar
      Fin-SI
      Fin-SI
Fin-SI



Autor: Ing. Liliana Suárez.


Si te pareció interesante el artículo reenvíalo a un amigo, haciendo click en el sobrecito que está al final del artículo. El conocimiento es valioso, compártelo.