Escrito en 1995 Para Documentar un sistema en red

Las reglas de programación citados mas abajo, representan el núcleo de los principios de programación de un servidor. En algunas ocasiones se verán cambios o partes de código que no siguen el esquema común del código; esto se debe a las indicaciones señaladas por el proceso en sí o por pedido del cliente.

Debido a que el acceso a las bases de datos es constante y en red el acceso es simultáneo, la red siempre se verá afectada por el número de archivos abiertos. Si se abren y cierran los archivos continuamente, la carga de red se altera de manera proporcional a la rapidez del equipo, y solo afecta el rendimiento de la terminal independiente y no de todos los nodos de la red.

Este sistema optimiza el código para aprovechar la velocidad del CPU disminuyendo al máximo el tiempo en que un archivo se encuentra bloqueado por un usuario. Aunque este abrir y cerrar de archivos afecta la velocidad, solo lo hace en las máquinas que de todas maneras alentarían la red. Sin embargo se da preferencia a dejar libre memoria, ya que la diferencia en memoria disponible afecta el rendimiento. Aunque el sistema obliga a hacer un número infinito de reintentos, realmente solo afecta a los equipos con BENCH mayor a 2. (Ver nota mas adelante)

Para reducir la baja de rendimiento del sistema en un equipo no apto para el mismo, se optó por realizar un procedimiento de acceso semejante a una biblioteca, con la diferencia que el bibliotecario será el programa, y al utilizar de manera adecuada las rutinas de bloqueo de registros del lenguaje, se crea un código mas robusto, por lo que en caso de una caída de la red lo único perdido es la ultima transacción, que puede identificarse en segundos. Así se tiene la ventaja de preservar la integridad de las bases de datos, y adicionalmente es muy fácil identificar que usuario estaba usando una base, permitiendo una corrección de errores independiente del software de Sistema Operativo de Red, a la vez que facilita asignar la responsabilidad a un equipo o persona específico y no al sistema.

La misma capacidad de las máquinas que servirán como nodos fijarán la carga de la red aparente, ya que el sistema reacciona a la máquina y no a la red. Según los índices de Red de Norton Utilities, el tráfico de la información afecta el rendimiento solo en las maquinas MUY antiguas, sin afectar a los mas nuevos. Debe recordarse que los índices Norton de Red son mejores mientras mas grande sea el valor.

En el manejo de disco en red deben considerarse los siguientes puntos:

a )Netware crea un respaldo de los archivos borrados, dicho respaldo solo se elimina si se llena el disco (produce un mensaje de error) o si se da la orden PURGE. Este inconveniente lo provoca la red, porque el dar los PURGE es mantenimiento del administrador de la red y no del sistema de suministros.
b )Los archivos temporales no deben hacerse en la red, sino en la ruta establecida por la variable de entorno TEMP, y en su defecto, se recomienda que se direccionen al disco duro local, si hay espacio suficiente.
c )En algunos lenguajes por default el archivo temporal de memoria virtual SIEMPRE se hará en el directorio donde esté el ejecutable, si no es posible cambiarlo al disco duro ( en Clipper si se puede ) es necesario que el usuario tenga derecho de creación en ese directorio, o el sistema sufrirá una caída. Esto puede evitarse usando los parámetros SWAPPATH de Clipper, pero se recomienda usarlos al administrador de la red.
d )Si el disco al que apuntan los archivos temporales esta comprimido (dblspace por ejemplo) el rendimiento del sistema (y su integridad) decrecen a la tercera parte.

Se recomienda crear un proceso para medir los tiempos de acceso a red se que pueda llamarse en cualquier momento. Un procedimiento promedio muestra los resultados de una prueba de lectura/escritura secuencial en los modos Shared y Exclusive, dando como resultado el rendimiento real de acceso a archivos por nodo, independiente de la Red (aunque el CPU y disco del servidor influyen en la prueba, lo hacen por igual en cada nodo).

Usando el módulo anterior puede verse la gran diferencia entre máquinas nuevas y otras un poco mas antiguas. El sistema se diseñó para ser usado en máquinas Pentium2 y en la primera implantación real, el sistema contó con varias máquinas Celeron con 16 mb de memoria, puede notarse que la degradación del sistema no se debe al programa.

Debido a que el sistema en red espera una operación simultánea por varios nodos, hay que tratar de usar lecturas no exclusivas siempre que fuera posible, almacenando los campos necesarios en variables de memoria dejando el archivo cerrado excepto al leerse o escribirse datos. Para evitar que el carácter “fijo” de estas variables afecte los resultados, algunas operaciones solo pueden ser realizadas si hay un solo usuario en la red o con un nivel de acceso determinado en el sistema y/o en la red.

Como se mencionó anteriormente, el mantener archivos cerrados siempre que sea posible aumenta la fiabilidad del sistema. Por ejemplo, una operadora del sistema puede recibir una llamada de un cliente que no se exprese claramente, y en lugar de mantener el archivo abierto hasta que los datos sean introducidos, restringiendo por lo tanto el acceso de otros usuarios o procesos, este sistema asegura que en un lapso no mayor de 3 segundos, y esto es en casos extremos, el archivo estará disponible para el usuario que lo requiere. En pruebas durante el desarrollo el tiempo de acceso cambia entre 30 y 40 centésimas de segundo, y la integridad de los archivos se asegura usando los datos solo cuando se requieran. La experiencia ha demostrado que el tiempo total de atención a un cliente normal, por una operadora capacitada, se limita a 18 segundos desde el momento en que se levanta el teléfono hasta que se despide el cliente, tomando como base 10000 registros de clientes.

En la mayor parte de las tablas de CONSULTA no modificables, que necesiten la base abierta se trabaja sobre la base en sí y no sobre bases temporales. Esto es con el fin de presentar información mas confiable, causando uno de los puntos débiles del sistema, aunque esta debilidad es relativa, ya que en las pruebas en que se cortó intencionalmente la energía eléctrica, no se dañó la información. Como la base se abre en modo no exclusivo, no se pierde información en caso de fallas de la corriente eléctrica, pero mientras se esté usando la tabla, no es posible que otra terminal utilice un proceso que requiera exclusividad. En otras palabras, se debe dar prioridad a la actualización On-line de información que “solidez” relativa del sistema, si es necesario usar tablas directas sin cerrar la fuente de datos.

[color=#00FF00]Criterios de programación:

1. Salvo en casos excepcionales, solo un archivo de base de datos estará abierto a la vez. Ejemplo, al guardar en bitácora.
2. El usuario MAESTRO será el único autorizado para dar altas o cambios de usuarios del sistema, incluyendo niveles de acceso.
3. Un usuario no debería usar simultáneamente dos nodos. Sin embargo PUEDE hacerlo, al igual que el sistema de Novell. Las medidas de seguridad y los niveles de acceso adoptados cumplen y modifican parcialmente este objetivo y permiten detectar la razón de caídas del sistema.
4. La información en tránsito se evitará siempre que sea posible para evitar que los usuarios manejen información desactualizada , prefiriéndose leer nuevamente la información cuando sea necesario.
5. Entrada de datos por menús o tablas., list y similaresPara preservar la integridad relacional, debe facilitarse la introducción de los mismos a través de listas para evitar se introduzcan datos erróneos. Para aumentar otra opción en los menús (para descripción por ejemplo) es suficiente con modificar las características del mismo, y en las listas se carga por si solo el dato, y el código es autoexplicativo.
6. Aunque los Índices pueden agilizar la búsqueda, hay información que debería estar en orden consecutivo para evitar omisión de datos: Por ejemplo, no debería asignarse el número de ruta 41 si no hay una ruta 40. Siguiendo el ejemplo, si el número de Pipa que el usuario intenta introducir es mayor al que corresponde consecutivamente, aparecerá un mensaje pidiendo que capture previamente los registros intermedios, o fijará automáticamente el valor correcto. Es decir, si el ultimo registro es de la ruta 40, no debe permitirse otro registro nuevo que el 41. Aun así es valido hacer modificaciones a registros anteriores (1-40).Debe evitarse incorporar la función de edición directa en las tablas, ya que puede prestarse a error en la información capturada , porque suele suceder que se causen cambios no deseados.De manera adicional, es preferible evitar los índices para manejo en red, ya que al usar el índice la base debe abrirse en modo exclusivo, o realizando un número excesivo de comprobaciones, afectando esto al rendimiento del programa en red.Debe tomarse en cuenta que ciertas búsquedas deben ser secuenciales y por lo tanto el uso de índices resulta poco práctico. Para evitar las demoras en búsquedas no secuenciales debe tratarse de hacer búsquedas directas y/o inversas cuando es posible, y si se usa SQL con campos sencillos.
7. Las operaciones que solo debe realizar el Usuario Maestro, no aparecerán para otros usuarios, o marcarán un mensaje de Opción no disponible.
8. Los procedimientos y menús deben ser lo mas modulares posibles y reutilizables por otros sistemas.
9. Las variables locales serán desechadas siempre que sea posible para evitar efectos secundarios. NO DEBEN USARSE STATICS de manera indiscriminada por que afectan el volumen de memoria disponible y solo tienen visibilidad dentro del *.obj correspondiente. Debe restringirse el uso de Privates en lenguajes como Clipper, y de Public en sistemas como VB , y por lo tanto solo se usan en aquellas ocasiones en que realmente es indispensable.Aunque el uso de funciones y procedimientos Static para facilitar el encapsulamiento es una opción aparente, tiene el problema que aumenta los requerimientos de memoria del programa, por lo que solo debe usarse en Clipper en casos de procesos homónimos dentro de diferentes módulos.
10. Si se aplica, los procedimientos y funciones deberán de guardar pantalla, color y fuente siempre que estos sean afectados como resultado de su proceso, para eliminar efectos secundarios ( Encapsulado ). Además no deben dejar índices en disco duro, si se utilizan, ni bases abiertas ( si el sistema es de red ). Preferentemente no deben dejarse archivos o tablas abiertas.
11. El programa debe permitir modificaciones-adaptaciones para cumplir con las necesidades de empresas del mismo giro, pero con el mismo código..
12. NO DEBE PERMITIRSE BAJAS FISICAS O LOGICAS DE INFORMACIÓN QUE PONDRÍAN EN PELIGRO LA INTEGRIDAD RELACIONAL DEL SISTEMA
13. Se debe dar prioridad a Legibilidad sobre eficiencia de código, y a bajo consumo de memoria sobre velocidad.
14. En Clipper No debe utilizarse la instrucción SET DELETE ON salvo en casos indispensables, y siempre debe dejarse en OFF al salir de los procedimientos que lo utilicen.
15. Es importante recordar que el usuario debe tener acceso a TODOS los derechos de los directorios de red, ya que de no hacerlo se corre peligro de pérdida de información al reordenar, compactar, en procesos propios del programa
16. Es deseable que el programa diga “No puedo continuar debido a que AQUIROZ está usando el archivo”, a decir “el usuario esta usando el archivo”, esto hace que los usuarios estén mas tranquilos, y se den cuenta que muchas veces el error es de ellos y no del programa.

[color=#00FF00]Requerimientos de memoria (Clipper):

Según Nantucket los programas de Clipper 5.2 necesitan un mínimo de 120 en memoria convencional para funcionar, y 160 para un uso óptimo. Esta memoria debe sumarse al numero de Kb que reporta RTLINK, y estar disponible en memoria convencional ANTES de llamar al sistema. Ejemplo:

Memoria Total
Total RTLINK 311
Memoria Mínima 120 311+120 = 431
Memoria Recomendada 160 311+160 = 471
Algunos procesos necesitan mas memoria que otros, así que donde ha sido posible, se hacen comprobaciones adicionales de memoria disponible sobre la marcha. Esto es muy importante en los procedimientos que crean arrays de gran tamaño.

NOTA Sobre EXOSPACE:

El uso de EXOSPACE de Clipper 5.3 crea situaciones especiales de memoria. Se sugiere leer detenidamente el anexo correspondiente. Por otro lado, todos los chequeos de memoria que aparentemente sobran en 5.2, son necesarios para 5.3, pero después del crecimiento que ha tenido suministros, es posible que deban ponerse mas líneas de chequeo de memoria en lugares estratégicos.

Este es un ejemplo de licencia de uso de COMPONENTES, no de programas normales independientes, que me sirve como borrador para los controles desarrollados para empresas.

[color=#00FF00]¿Yo, usuario, soy dueño de CADMUS?

No. Todos los programas y procesos desarrollados para usted, excepto los contemplados en cláusula de confidencialidad, le dan una LICENCIA DE USO NO EXCLUSIVO, que le permite instalar nuestro producto en sus equipos de acuerdo a las restricciones estipuladas en el presente contrato.

[color=#00FF00]¿Qué es CADMUS?

Cadmus es un generador de Código que se soporta en la librería CADMUS.LIB

[color=#00FF00]Cual es la diferencia entre CADMUS LITE y CADMUS?

Cadmus Lite es una versión reducida de la librería Cadmus, con menos funciones pero mayor rapidez. Las opciones/funciones no incluidas, se refieren a mejoras para red. Si su sistema NO VA A USAR Funciones exclusivas e CADMUS para red, CADMUS LITE es suficiente.

Como se desarrolló para el uso personal del programador, y es un instrumento de programación, el autor no es responsable de daños o perjuicios que sean causados por el uso, abuso, mal uso o ingeniería reversa sobre CADMUS.EXE (el generador), o sobre programas que se hayan elaborado con las rutinas de CADMUS.LIB, CADMUS87.LIB, CADMUS50.LIB o CADMUS53.LIB o sus versiones LITE.

El autor de CADMUS renuncia de manera expresa a cualquier prestación que correspondiera por el uso de la librería en programas de terceros, pero al renunciar a los derechos, de manera tácita renuncia a las obligaciones que pudieran generarse de la misma.

Si es usted uno de los clientes , y no realizó el pago completo, para fines de la ley de derechos de autor, usted tiene una versión de prueba, y al no haber recibido pago completo por el programa, no hay obligación de ninguna de las partes, porque el programa NO EXISTE.

NOTA: El soporte obligatorio a las librerías CADMUS o CADMUS LITE, en caso de ser aplicable, estará limitado a la versión entregada para el proyecto específico, es decir, si se le entregó CADMUS LITE no se dará soporte para CADMUS, y viceversa.

Las actualizaciones a Cadmus pueden conseguirse gratuitamente en diversos sitios de Internet, entendiendose que el soporte a programadores o usuarios, SOLO SERA OBLIGATORIO EN PROGRAMAS HECHOS POR UN SERVIDOR, Y EN LA LIBRERIA, LITE O COMPLETA ENTREGADA ORIGINALMENTE, limitándose el soporte si se ha realizado intervención por terceros. Si usted como programador usa esta librería, puedo solucionar sus dudas, pero no tendré obligación de hacerlo por ser una utilería FREEWARE.

Como se explica en la documentación de CADMUS.EXE, he tratado de generar código claro y limpio de errores. Espero que CADMUS sea una herramienta muy util para usted.

Si el programa no se le entregó a usted con CADMUS LITE, es posible que el programa compile con BLINKER de 5.3, pero por su tamaño se diseñó para usar modo protegido. Solo realicé pruebas intensivas con Clipper 5.2, por lo que es posible que BLINKER no permita liberar los recursos necesarios. Debe notarse que cuando hay muchos procedimientos, solo EXOSPACE puede llevar el control de tantos procedimientos, sin marcar “supuestos” errores de operación, porque todas las rutinas estan en *.prg o CADMUS, pero el número de procedimientos puede rebasar el tamaño de la tabla de símbolos de modo real.

Es importante recordar que el equipo en que se compila necesita solo 2 MB de memoria, pero aunque EXOSPACE compila, se tarda horrores. Para una velocidad aceptable se requieren 8 MB.

Como programador que vive de su trabajo, he adquirido un Modus Operandi específico, y destaca el no trabajar sin un anticipo, y entregar el código fuente de todo trabajo que se haya desarrollado PARA CADA PROYECTO. Sin embargo, el código de CADMUS.LIB es el fruto de casi 4 años de trabajo, e incluye rutinas especializadas de seguridad, que además que no se aplican a la mayoría de los proyectos, NO PUEDEN DISTRIBUIRSE PORQUE SE ESTARIA VIOLANDO EL CONTRATO CON OTROS CLIENTES QUE SI REQUIEREN DE ELLA.

Con el programa se entrega una versión actualizada de la librería CADMUS.LIB, así como dos archivos llamados CADMUS.LIC, que es la licencia de uso de la librería (cuyas condiciones cubren sobradamente el requisito de dejar el código del programa), y CADMUS.INT, que son las cabeceras e interfaz de la librería, con excepción de las rutinas de seguridad.

Es importante considerar que CADMUS.LIB se ha compilado con CLIPPER 5.2e, por lo que es importante revisar el archivo COMPILA.BAT. En caso de que usted este utilizando Cadmus53.LIB o una versión mas reciente de algun BBS, recuerde que si utilizó EXOSPACE el reloj se desactiva automáticamente.

Por favor, no insista en pedir la interface de las rutinas de seguridad, ya que las empresas que lo utilizan tienen contacto frecuente con un servidor.

Al revisar el correo encontré unos comentarios de uno de ustedes, diciendo que los modelos lógicos son muy prácticos. Si, lo son, siempre y cuando estemos hablando de diseño de aplicaciones a secas, no de RAD, diseño RAPIDO de aplicaciones, y que el analista sea el mismo que el programador. Muchas personas que no saben programar o de bases de datos, son capaces de hacer esquema lógico. Pero un modelo físico decente es raro, y mas raro alguien que lo pueda hacer a la primera.

Una mentira frecuente que se oye, o error a medias, es que un buen modelo de datos hecho en dos semanas, puede hacerse en una semana la programación, y se ahorra tiempo sobre un diseño/sistema normal de cuatro semanas. El problema es que como suele ser diferente la persona que hace el análisis al que hace el programa, suelen verse a veces cosas ridículas tipo teléfono descompuesto, y a nivel programación entender el proceso lógico y aterrizarlo a datos puede dar muchos problemas. Es común que alguien debe hacer un programa sobre el diseño de otra persona, sin poder corregir errores del análisis original.

Voy a citar dos ejemplos que me pasaron a mi.

caso a)

En una empresa que me contrató me pasaron un manual de 200 paginas por mail hechas sobre un modelo de datos de Data Arquitect. Para mi resultó obvio que no lo iba a poder leer, me negué a recibirlo, y después me pasaron un esquema de una hoja lógico, sobre el modelo físico.

Una vez que tuve casi terminado el sistema, y se mandó a una persona a instalarlo, me di cuenta que todo el modelo estaba hecho sobre el supuesto de que algo llamado “sesión” era único y era la clave de todo un esquema. Pues al confirmar un dato con el usuario.. resultó que la sesión se repetía a diario. Ese “pequeño” fallo lógico no hubiera sucedido si el analista hubiera hecho antes una sesión de preguntas con el usuario.

caso

En otra empresa, la que mencioné antes sobre conciliaciones bancarias, recibí una impresión de 9 hojas siendo una maestro y otra detalle sobre un proceso de consolidación de sucursales. En papel se veía muy bonito, pero si ustedes ven que un modelo dice Facturas suponen que es facturas, pero si ven un esquema con las tablas donde se ven las relaciones NO hay dudas. Si el titulo dice “Consolidación de facturas”, suponen que se refiere a facturas, no a cuentas por cobrar.

En ciertos casos si es conveniente crear modelos lógicos, pero no en RAD. En todo caso, crear el modelo Lógico después de terminado el programa. El modelo físico si se debe hacer sobre al marcha, [color=#00FF00]Y ES EL QUE DEBE USARSE COMO BASE.

Por lo general este es un tema que se brinda a muchas discusiones, pero normalmente se entiende casi por default que nos referimos a esquemas de Power Designer de Sybase. Los Modelos Lógicos con extensión PAM se crean con el Process Analyst, y los físicos con Data Arquitect Extensión PDM. Mas adelante hablaremos de las limitaciones de esos programas, pero son menores a las de Visio o los productos de Embarcadero

Por otra parte, un modelo lógico valido debe ser consultado con el usuario antes de hacer algo realmente complicado ( eso dice Yourdon ), y los modelos RAD suelen ser sencillos. Si alguien hace un modelo lógico complicado, y sobre el nos pide que hagamos RAD, nos quita el criterio que es necesario para desarrollar RAD. Además, la lógica de un modelo no necesariamente se aplica a los datos de que hablamos.

Dicho de otra manera, un modelo lógico no necesariamente habla de interacción con Datos. Y los datos no necesariamente siguen un modelo.

En días recientes me vi en la necesidad de explicar a una serie de abogados y contadores un esquema bancario aparentemente complejo, con el cual se evitan los problemas actuales de una organización. Pero para explicarlo en términos lógicos, NO DE DATOS, tuve que reducirlo a los elementos comunes de un esquema lógico:

1. Entidades
2. Procesos
3. Receptores de datos ( NO NECESARIAMENTE Tablas o bases )
4. Y sus relaciones.

El resultado de esto fue un esquema que les envío, esta hecho en Process Analyst y yo lo convertí a PDF, verán que la frase de “Esquema personal de bancos” sale encimada, pero se debe al proceso de conversión. Si ustedes imprimen el modelo, verán que no es tan complicado por la división en grupos y la explicación contigua.

En este caso las entidades son los bancos ( rectángulos ), los procesos los círculos, y los rectángulos a medias las cuentas de banco. El proceso en especial puede verse demasiado complicado de entrada, pero no necesita explicación adicional, y explica un proceso realmente complicado en términos No técnicos. Ahora bien, un modelo de este tipo se entrega en una pagina, la persona lo revisa sin problemas porque no tiene ramificaciones. Si quiere saca una copia y la raya, pero es a final de cuentas, un resumen Lógico, que es lo que debe ser un modelo lógico. Y me repito pero nunca lo suficiente. Un modelo comprensible sea LOGICO O FISICO debe de ser Pequeño, de 1 a 4 Páginas SIN RAMIFICACIONES y Subdocumentos

La parte técnica seria un modelo físico de datos sobre las transacciones a cuentas bancarias, pero como se dan cuenta, el modelo lógico es de procesos , pero no de DATOS. El modelo físico si nos da relaciones entre los datos.

[url=http://darakan.com/images/esquem.pdf]http://darakan.com/images/esquem.pdf[/url] (link roto de manera temporal )

22/febrero/2001

Justamente hace unos minutos alguien me preguntó como exportar datos a Excel .Como he dicho antes , es muy importante que el codigo sea generico y reutilizable.

Aunque a los que no programan mucho esto puede sonarles en chino, les envio un codigo que exporta un recordset ( un resultado) a Excel, sin problemas.

Hay un detalle importante, ustedes encontrarán codigos similares que truenan por una comprobacion “Sobrante” que esta aquí. Estos son los llamados, tipos fuertes, es decir, ustedes no pueden sumar dos cosas de diferente tipo.

Aunque mas adelante veremos a detalle los tipos fuertes, esta funcion es muy sencilla y facil de usar, el secreto es el cstr. Aparentemente sobra, pero si no quieren llevarse en ciertos casos un error 1004 applicattion defined error.

Este código solo considera las primeras 256 columnas pero ampliarlo es simple.

El nombre viene de que convierte de Rs ( recordset ) a Excel (en notación antigua rs2xls)

[code]Private Sub Rs2XLS(rs As ADODB.Recordset)
Dim d As String

rs.MoveFirst
On Error GoTo etiqueta

El desarrollo tiene dos etapas siempre, la primera es el desarrollo en sí, y la segunda es el mantenimiento. Los sistemas que valen la pena no se archivan en un cajón, porque se estan usando y nos piden cambios; los buenos programas se usan y se usan y se usan y se piden modificaciones, y .. los buenos programadores las hacen. En lo personal, una de las cosas que mas me agradan es que la mayor parte de los programas que he realizado siguen en uso, incluso los que han sido sustituidos por versiones mas nuevas de otros programadores, son conservados en reserva para checar los datos. Como les consta a varios, los sistemas me avisan cuando hay cambios de hardware, de software, cuando sacan respaldos, etc incluso aunque ya no labore en esa(s) empresa(s).

Seguramente les ha de haber tocado a algunos, checar el código hecho por otra persona. Ese código no necesariamente es malo o bueno. Algunos si son complejos, otros no tanto. Pero si somos los programadores de mantenimiento, sea de programas ajenos o propios, lo primero que debemos hacer es aplicar la navaja de Occam. Simplificar.

[blockquote]Pero si vale la pena el esfuerzo. En la empresa en que entré en el año 2004, usaban un programa reliquia hecho en TP3, ese sistema es uno de los mejores ejemplos de lo que no se debe hacer. Tenian ademas 28 versiones de ese programa, diferentes en cada centro de distribución, con diferentes estructuras de datos. Si el sistema hubiese estado igual en los 28 depósitos o con la misma estructura de datos, seria factiuble hacer algo, pero en las condiciones reales, lo mejor era cambiar por otra cosa, inclusive el SAE.[/blockquote]

Recordarán ustedes que les comenté hace unos correos, que resulta mas facil realizar varios cambios chicos que uno muy grande. Esto se debe a diversas razones, pero sobre todo, le permite al usuario darse cuenta que realmente hay un cambio de una versión a otra, y adaptarse con mayor rapidez, despues de tres cambios chicos relativamente, el usuario puede tener un sistema diez o veinte veces mas rapido, sin aprendizaje aparente.

Los principios de RAD, lo que hacen su esencia, son .. permitir desarrollar y mantener un programa de una manera rapida de una plataforma a otra, evitando la necesidad de hacer manuales de ocho paginas, y juntas de comites que decidan como sacar cada reporte.

RAD está orientado a los usuarios, pero al mismo tiempo nos simplifica la vida como programadores; Pero la importancia del criterio del programador resulta decisiva, aunque desgraciadamente en el medio de las computadoras hay demasiados asesores, consultores, etc, y si a un programador le quitan su criterio, que queda? NADA. Literalmente hablando. Napoleón decia, si quieres que las cosas se hagan nombra un responsable, si no quieres que se hagan, nombra un comité. Y esto se debe a una pelea entre la autoridad y la responsabilidad; RAD se basa en que se tiene la autoridad y la responsabilidad. Si no se tiene una de las dos, no es RAD.

Todo esto sale por que ayer me enviaron dos archivos por correo electrónico: Uno se llama eValua51.zip, que es un administrador de proyectos RAD, y otro es un programa de Visual Basic. Lo curioso es que el “entorno de RAD”…. usa 10 pantallas diferentes con conceptos no explicados en un modelo ni claros en la misma pantalla, y calcula para proyectos de mediano tamaño un promedio de 90 dias del inicio de la planeación a su termino, en un equipo de 4 programadores. Se oye muy bonito, pero NO ES RAD.

La esencia de RAD es RAPIDO y eficiente, y con prueba de errores. Maximo una semana.

Un programa que otros han hecho, puede ser considerado o no RAD. Pero vamos a ver el caso del otro programa que me enviaron, que revisa si hay mensajes nuevos en una cuenta de correo; tiene la aparente ventaja de que permite ver varios idiomas, pero no esta muy documentado. El archivo se encuentra en [url=http://#]images/antes.zip[/url], el modificado para ser RAD está en [url=http://#]images/despues.zip[/url]; si estas leyendo esto en un correo, he puesto los dos archivos en un mensaje.

Tengo que aclarar que cuando escribí este correo/pagina no estaba conectado a Internet; no probé ninguno de los dos programas, pero si se fijan el segundo programa resulta bastante mas sencillo de entender por el nombre de los controles, y en cuanto a tamaño… tiene el 75% del tamaño, y se ha dejado el modulo ( el archivo bas ) como código listo para volverse control.

Otro detalle es que se conservó la esencia del sistema original, por lo que el usuario no tendria problemas en adaptarse a la nueva versión. Quizá podriamos poner adornos, como bloquear la configuración, o elegir idioma; lo que me parece urgente ajustar en el programa, es eliminar el archivo de recursos que quita bastante claridad al código, y poner la opcion de revisar varias cuentas.

Estoy seguro que una vez que abran el archivo original, no importando su grado de conocimiento de Visual, no le van a entender nada, y para modificarlo tampoco. Y eso que esta en español.

Si bien el programa es bueno, y se supone que funciona, tiene tantos detalles para demostrar “el virtuosismo” del programador, que se llega a un extremo en el que se vuelve casi imposible de modificar, ineficiente.. y seguramente los detallitos se tardaron mucho mas que el programa en si. Tampoco es RAD.

Lo que busca RAD es tener programas faciles de modificar y reutilizar, y de entender. No solo por el usuario, tambien por el programador.

——————————————————
Alfonso Orozco – Junio 2001
ICQ 41907900

Se que el titulo de esta lección suena bastante raro. Que puede tener de malo hacer bajas por SQL? La respuesta es sencilla. Es demasiado eficaz. Si alguno de ustedes por error ha usado el del *.* donde no debía, sabrá a lo que me refiero. O para mas detalles, el “virus” sulfbnf.exe o como se escriba. Las bajas SQL pueden ser uno de los modos mas rapidos de darle en la torre a toda una tabla de datos, y sin posibilidad de recuperación.

Esta es su unica desventaja.

Ventajas, pues son bastantes. Rapidez, funciona en SQL server ( el metodo DAO muchas veces no jala en SQL 6.5 ). No hay que aprender ninguna sintaxis en especial, pero al mismo tiempo debe ponerse especial cuidado en lo que se hace.

En Dao Tradicional ( o en ADO no orientado a SQL ) hay un metodo llamado Delete, que pueden buscar en la ayuda de VB, y que tiene como principal problema una serie de ajustes necesarios si se da baja del ultimo registro.

Todos hemos visto en algun programa un aviso que diga “pulse ESC para cancelar”. Si querermos hacer eso en bajas de una base de datos, tenemos que usar la sintaxis DAO, porque la SQL es DEMASIADO Rapida, y antes de liberarse debe hacerse una prueba de lo que realmente estamos borrando. Incluso en casos ideales, deberíamos mostrar al usuario lo que realmente está borrando, si el resultado es mayor a 5 renglones.

En SQL las bajas se hacen como un parámetro del metodo Execute, el mismo que nos hace dar altas. Ustedes recordarán que decíamos que hay dos procesos SQL, filtrar o realizar acciones. Vimos por ejemplo que para filtrar, usabamos una sintaxis de este tipo:

SELECT * from ALUMNOS where EDAD>18

Supongamos que queremos borrar esos alumnos. La orden DAO/ado NO sql sería mas o menos así:

[font=Courier New]dim rs as dao.recordset
set rs= db.opendatabase(“SELECT * from ALUMNOS where EDAD>18”)
with rs
[color=#000000]……do until .eof
[color=#000000]……… .delete
[color=#000000]……… .movenext
[color=#000000]……… doevents
[color=#000000]……. loop
[color=#000000]…… .close
end with
set rs=nothing [/font]

Pero la orden en SQL es muchisimo mas simple:

[font=Courier New]db.execute(“DELETE * from ALUMNOS where EDAD>18”)[/font]

Obviamente este proceso es mucho mas rapido. Sin embargo, por cuestiones de diseño sale un detalle que en SQL es completamente obligatorio, al que se le llama “Llave Primaria”, Por ejemplo, no puden haber dos clientes con la misma clave, estamos de acuerdo? Esto es para evitar que en una baja SQL, demos de baja algo que no queremos dar de baja. Este problema de borrar tablas por error, se aplica sobre todo a la mala costumbre de algunos programadores de usar frases como “select * from alumnos” Que claro se escribe muy rapido y es valida si no nos preocupan los efectos de memoria, pero se imaginan lo que hace un “delete * from ALUMNOS” ?? Si. Exactamente lo que pensaron.

Esta es otra de las razones para usar nombres de campos sencillos, si sabemos por ejemplo que ALUM_CVE es la clave, es mas facil acordarnos que con un ALUMNOS_VIGENTES_ID.

Algo que me ha funcionado muy bien, es crear una rutina especial para dar bajas de datos. Al igual que la que vimos hace unas semanas, aparentemente no funciona por el metodo execute no reconocido. Como les dije en su momento, ese metodo se refiere a la basededatos as database de DAO, o a la conexión de un ADODB.COnnection en ADO.

[font=Courier New]Public Function Elimina_Reg(ByVal Nombre_Tabla As String, & _
[color=#000000]…….. ByVal Campo_Llave As String, ByVal Valor_Llave As String) As Boolean

‘Nombre[color=#000000]……..Elimina_Reg
‘Objetivo[color=#000000]……Eliminar TODOS los registros que tengan una
‘[color=#000000]…………..condición dada ( valor de campo llave )
‘Regresa[color=#000000]…….Verdadero o false segun el resultado
‘Parámetros[color=#000000]….Nombre_Tabla Nombre de la tabla de datos
[color=#000000]……………Campo_Llave Cadena con nombre del campo llave
[color=#000000]……………Valor_Llave Cadena con el valor que debe tener la llave
[/font]

‘Ejemplo:

[font=Courier New]’Eliminará todos los clientes de la colonia Polanco
‘borrado= Elimina_Reg(“CLIENTES”, “COLON”, “POLANCO”, true)

‘ Por razones Obvias debe usarse con cuidado

[color=#000000]……….. Dim strSQL As String
[color=#000000]……….. Dim strMensaje As String
[color=#000000]……….. Dim blnConfirma As Boolean
[color=#000000]……….. If IsNumeric(Valor_Llave) Then
[color=#000000]…………. strSQL = “DELETE FROM ” & Nombre_Tabla & ” WHERE ” & _
[color=#000000]…………….. Campo_Llave & ” = ” & Valor_Llave
[color=#000000]……….. Else
[color=#000000]…………. strSQL = “DELETE FROM ” & Nombre_Tabla & ” WHERE ” & _
[color=#000000]…………….. Campo_Llave & ” = ‘” & Valor_Llave & “‘”
[color=#000000]………. End If
[color=#000000]……….. blnConfirma = Execute(strSQL)
[color=#000000]……….. If blnConfirma = True Then
[color=#000000]…………. strMensaje = “El registro con clave: ” & _
[color=#000000]…………….. Valor_Llave & ” ha sido eliminado”
[color=#000000]………….. Call MsgBox(strMensaje, vbExclamation, “Borrar Registros”)
[color=#000000]……….. Else
[color=#000000]………….. Call MsgBox(“*** Registro No eliminado ***”, vbCritical, “Borrar Registros”)
[color=#000000]……….. End If
[color=#000000]………. Elimina_Reg = blnConfirma
End Function[/font]

Una función de este tipo es mucho mas práctica que tener DELETE por todos lados. Si ustedes necesitan borrar si se cumplen dos o tres campos llave, pues… les recomiendo modificar esta funcion pára manejar varios parámetros, o usar la sintaxis DAO/ADO no SQL.

En la proxima lección, veremos un poco de los cambios en SQL, que si bien son mas rapidos, suelen ser mas complicados, aparentemente.

————————————————–
Alfonso Orozco – Mayo 2001
ICQ 41907900

Por favor, recuerden que lo que menciono en este sitio o correos es fruto de experiencia personal y del uso de RAD. No es la biblia pero tiene sus bases, aunque ustedes tomen la decision final de si me hacen caso o no. Uno de los principios RAD, es que debe considerarse el criterio del programador como válido, siempre. Y no es cualquier principio, es el primero y fundamento de todo lo demás.

Si ustedes quieren tener un sistema portable, deben de tener tablas que usen nombres de 10 caracteres en Mayusculas, y con inicios diferentes. Un compañero me mandó una base Access 97, que les adjunto en otro correo y que puede consultarse aquí. El objetivo de esta base es llevar un control de quien tiene que equipo de computadora en que sucursales.

Quiero que se fijen que en mi análisis solo me voy a referir a los nombres y no a los tipos de campos, acepto como válido el criterio de tipos, porque pueden haber referencias específicas. También acepto como buenas las relaciones o no que el programador ha hecho, y todo lo que sigue son simplemente comentarios para facilitar la implementación, pero al mismo tiempo, facilita que otros programadores usen el código, y poder usarlo para llevar un control de cualquier equipo, y no solo en la sucursal.

Sugiero que antes de seguir abran la base de Access, o vean la imagen que está al final de este correo/ hoja web,aquí

[font=Courier New]Tablas en inventario.mdb[color=#000000]………….Sugerido
———————————————————————-

Si bien es cierto que las aplicaciones modernas pueden correr sobre un montón de plataformas, en la práctica tenemos pocas opciones reales.

Frecuentemente me preguntan.. tengo problemas con el Access 2000, que hago ? Y el problema es que una aplicación con Access 2000 debe de tener instalado en las maquinas destino el motor ( preferentemente DAO 3.6 ) para ese formato. Si usan access usen el formato 97 y quitense de dolores de cabeza.

He comentado que hay pocas opciones, pero antes de explicarlas una por una, nuestro sistema debe de ser portable, esto es una característica de RAD. Porqué? Bueno, anteriormente comenté que debemos programar en base al Acceso, no a los datos.

En febrero de este año una empresa me pidió que hiciera un sistema basado en ORACLE. Yo no sabía con que versión iba a trabajar, asi que lo primero que hice fue con el Data Architect un modelo físico suponiendo que iba a usar Access 97. Un poco mas adelante en el proyecto, resultó que alguien se dió cuenta que era contraproducente usar el servidor ORACLE disponible, y me dijeron que pasara a SQL Server 7.0. Y cosa de un mes después se dieron cuenta que el sistema no podía usar el servidor SQL, y lo terminé pasando a Access. Pero no tuve que cambiar nada cada vez, excepto una linea de código. Por la manera en que se hace el diseño, cambir de plataforma puede ser una pesadilla o muy facil.

Pasando a los soportes físicos tradicionales, podemos usar varias alternativas:

1. [color=#FFFFCC]Access 2000 – Tiene ventajas supongo, pero también el gran problema que si se instala en una PC que usa office 97 puede desconfigurarla casi completamente. Por otra parte necesita mas recursos que Access 97, y obviamente no es compatible hacia atrás, es decir, access 97 no puede abrir una base access 2000, lo que puede ser una ventaja. Su clave de provider JET es 4.0 ( luego vemos que es eso ), y su requisito es MSDAC 2.6. Ojo, si usan DAO es 3.6.
2. [color=#FFFFCC]Access 97 – Su ventaja principal es que es el motor incluido en VB5 y VB6. En una empresa me tocó realizar una serie de procesos con una tabla Access, pero ni siquiera tenía Access. Conociendo las sintaxis DAO/ADO, no es necesario pagar por el soporte de Access, y esto impide que los clientes lo modifiquen desde la base y puede disminuir costos. Su principal problema es que es poco resistente/estable para una aplicación grande/mediana que usen varias tablas. Los de las gaseras, recordarán como avisé con UN AÑO Y MEDIO DE ANTICIPACION, los problemas que iban a tener si usaban Access y nadie me creyó. Lean los comentarios en las lecciones anteriores sobre access para mas señas. Su clave de Provider JET es 3.51 y su requisito es MDAC 2.0 o 2.1.
3. [color=#FFFFCC]SQL Server 6.5 – Su ventaja principal es …. que no es la versión 7.0 !!! Como es eso ? Bueno, tiene soporte para muchas funciones, procedimientos almacenados ( que no recomiendo luego vemos porqué ), pero no tiene lo que se ha dado en llamar TRANSACT SQL , característica de la versión 7.0. Sus desventajas son que ya no está a la venta, pero si existe el precio lo justifica. No tiene problemas de Mayúsculas Minusculas en nombres, lo que puede ser una ventaja. Se usa el acceso standard de provider, que puede ser el incluido en Office 97, en VB, o usar las versiones OLEDB. Necesita un servidor dedicado, pero hay que tener acceso a el para modificar los datos a mano, y saber el proceso. Muy robusto, y al igual que la versión 7.0, permite dar accesos al usuario por tabla ( borrar, cambiar, etc )
4. [color=#FFFFCC]SQL Server 7.0 – Su ventaja real es que hay una versión demo de 120 dias, y una gran característica es que en la instalación hay una versión “Desktop” en el mismo CD, que hace que tener un servidor sea opcional. Otra ventaja es que podemos programar y probar en una sola máquina sin servidor. Tiene un chequeo de nombres completamente funcional, pero configurarlo puede ser un problema. Soporta Triggers, store procedures y otras chunches que no son del standard ANSI SQL, pero si se usan el sistema es menos Portable. Si bien esas chunches son “necesarias” para un desarrollo en capas, a mi parecer se pierde en portabilidad. Si usan este servidor, tengan cuidado al configurar el tamaño de las bases de bitácora o LOG. Me tocó con una aplicación que usaba acceso intensivo, que las tablas necesitaban 10 mb.. y el log de transacciones 260 !!! Porque se cargaban archivos continuamente. En ciertos casos es preferible poner a ceros el Log. A mi parecer es el mas sólido de los productos SQL, si no se usa Transact. Otro problema:. NO RECUPERA SUS PROPIOS RESPALDOS cuando estos son complicados. Mas adelante veremos esto, pero Para Lucent Technologies tuve que hacer un programa especial de respaldo. Al igual que su antecesora, usa los drivers default de Windows y VB. Siempre que me refiera a usar SQL server, me refiero a esta versión SIN USAR TRIGGERS Y STORE PROCEDURES !!!.
   

   En el año 2004 la empresa en que laboro compró un sistema de nómina relativamente robusto que necesitaba SQL 7, pero hubieron dos problema bastante desagradables. El primero fue que una tercera empresa, que daba mantenimiento al servidor, instaló Panda antivirus en el servidor SQL, y el sitio de Panda dice claramente que es incompatible con SQL7. De repente nos quedamos sin SQL corporativo, sin manera de hacer respaldos, etc. Pude levantarlo tras dos meses de trabajo con imagenes GHOST y sin reinstalar. El segundo problema fue una falla del disco duro que me obligó a cambiarlo a otro disco del mismo servidor. La falla en este caso fue porque el sistema de nómina validaba muchas cosas por Stored procedures e inicios de sesión. Sin entrar en detalles tuve que hacer circo maroma y teatro para reinstalar la base de datos y restaurar inicios de sesión y derechos de usuario, pero debidas a fallas de diseño del sistema de nómina.

5. [color=#FFFFCC]MSDE – Esta es una versión limitada del SQL Server 2000 mezclada con Access. Puede ser util si quieren usar el Access 2000 como servidor corporativo. No puedo dar muchos detalles, pero en teoría solo permite cinco usuarios.
6. [color=#FFFFCC]DBF – Este formato tiene una mirada de desprecio por parte de muchas personas. Pero tiene varias ventajas a favor. Es condenadamente rápido y pequeño. Por ejemplo, supongamos que tenemos un proyecto que usa dos tablas de tamaño mediano, que en total miden 3 mb. En Access 97 estas tablas pueden llegar a formar un MDB de 6 a 10 mb. Tienen el inconveniente que muchos desarrolladores diseñan aplicaciones VB tratando de coexistir con índices de Clipper y esto no es posible; debe desarrollarse de un modo un poco diferente, y preferentemente NO usando motores externos. Otra de sus ventajas es que para aplicaciones en Internet y JAVA ( no confundir con Java script ) Puede usarse directamente. Mi recomendación basica es.. usa los indices de VB, No te compliques con NTX, CDX o indices diferentes. Otra ventaja es que soporta cualquier tipo de acceso, de ODBC a ADO. Un detalle curioso, en una empresa que usaba people soft, tenía que instalar una aplicación VB5-DAO con estas bases, pero el rendimiento era infame. Lo que hice fue, believe it or not ( aunque usted no lo crea ) , cambiarlo a … VB3 !! Con data control. Menos recursos y mas rapido. Siempre que me refiera a este formato, me refiero al provider “dBase III;”

Algo que para mi es un principio de sentido común y al mismo tiempo RAD, es hacer un diseño que no suponga que el cliente tiene la ultima tecnología. Hace unos meses con algunos negocios usaba un sistema de vb5-Access que mandaba por Internet actualizaciones. Obviamente necesitaba W95, etc etc. Y de repente, se abrieron diez sucursales mas. Lo que hice fue conseguir 10 computadoras 286/386, realizar una versión con VB4 a 16 bits ( windows 3.1 ), conectarlas a Internet…. y el cliente se ahorró 20 mil pesos, y yo me gané 10 mil sin tener que cambiar gran cosa en el programa.

En dic de 2004 todos esos sistemas siguen funcionando… con modems externos y portatiles 286 y 386 en varias sucursales.

En el próximo correo, un ejemplo rápido de esto y como hacer un diseño de datos ( modelo físico ) compatible con lo que sea , y relacional.

——————————————
Alfonso Orozco – Mayo 2001 Actualizado Octubre 2004

Aunque aparentemente no tiene nada que ver, les voy a pedir que instalen por favor el Acrobat Reader, si no lo tienen lo pueden encontrar en casi cualquier disco de ShareWare o en [url=http://www.download.com/]www.download.com[/url], lo necesitarán dentro de poco, ya que mandaré material en ese formato, y además varios de ustedes me pidieron que subiera todo como material de referencia en un solo documento, y lo subiré como PDF.

Como dice el nombre de esta lección, existen dos procesos básicos que pueden hacerse con SQL, el proceso que vimos anteriormente en la lección ocho,

Acceso a Datos 08: Un poquito de SQL

un poquito de SQL[/url], eran las cláusulas SELECT, que tenían como propósito el filtrar la información que necesitamos, para devolvernos un “recordset”, o conjunto de resultados. Los que han usado Access, están acostumbrados a usar la expresión “querys”, para indicar lo mismo, por eso de aquí en adelante me referiré a ellos como Query, aunque realmente me refiero al conjunto de resultados de un SELECT en SQL.

El segundo proceso básico de SQL, son las acciones sobre un conjunto de datos; pueden ser cualquiera de los procesos ABC, así como crear tablas nuevas o añadir información de otras.

En el caso de DAO, el primer proceso se hace a través del objeto database y su método openrecordset, y en ADO se realiza con la conexión ADODB Vigente y su método OPEN.

En el segundo proceso, DAO usa el método EXECUTE del objeto database, y ADO el mismo método pero del objeto adodb.connection.

La sintaxis que se usa es demasiado amplia por lo general para poder abordarla aqui con detalle, pero a grandes rasgos este es el código necesario para dar un alta en DAO a través de SQL.

Como hemos hecho antes, pondremos // para indicar que lo que sigue debe de ir en la linea anterior.

‘ se supone que los datos que queremos guardar están en
‘ las tres variables del correo anterior, strnombre, strclave y strnota
dim strsql as string
strSQL = “INSERT into bancos ( BCO_CVE,BCO_NOM,BCO_NOTA ) VALUES ( ‘”& STRCLAVE
// “‘,'” & strnombre”,'” & strnota &”‘)”
mibasededatos.execute strsql

EN DAO tradicional la orden sería así:

dim rs as dao.recordset
set rs=mibasededatos.openrecordset(“select * from BANCOS”)
with rs
[color=#000000]……… .addnew
[color=#000000]……… .fields(“BCO_CVE”)=strclave
[color=#000000]……… .fields(“BCO_NOM”)=strnombre
[color=#000000]……… .fields(“BCO_NOTA”)=strnota
[color=#000000]……… .update
[color=#000000]……… .close
[color=#000000]…….end with
[color=#000000]…….set rs=nothing

Cual creen que sea mas rápido?. Podemos incluso hacer una función genérica que realice el proceso por nosotros, y quedaría una sola línea:

agrega_datos(“BANCOS”,”BCO_CVE,BCO_NOM,BCO_CTA”,”‘” & STRCLAVE “‘,” &
// “‘” & strnombre “‘,'” & strnota &”‘”)

OJO:Fijense que entre el nombre de las variables hay un apóstrofe. Una de las pocas limitaciones de SQL es que nos obliga a poner entre comillas simples ( ascii 39 ) las cadenas de caracteres que pasemos como parámetro. Si estuvieramos usando números, no habria problemas SI NO TIENE COMAS; Para pasar un boolean, poner true or False sin comillas es suficiente. Por cierto, las fechas tienen una limitación especial que veremos en unos cuantos correos, las ignoraremos por ahora. Si quieren pasar un valor Nulo, se pone la cadena Null, sin comillas

A continuación les pongo la función que utilizo, en DAO y en ADO para dar un alta. Aparentemente no funciona, porque no existe la orden EXECUTE. Eso esta pensado; si quieren usarla ahora solo cambien execute por adodb.connection.execute si usan ADO, o midatabase.execute si usan DAO. Yo les sugiero que se esperen, y mas adelante veremos como migrar de DAO a ADO no es difícil si usan las sentencias SQL en lugar de las ordenes .addnew que vimos arriba.

Public Function Agrega_Reg(ByVal Nombre_Tabla As String, _
[color=#000000]…….ByVal pstrCampos As String, _
[color=#000000]…….ByVal pstrValores As String, _
[color=#000000]…….mostrarmensaje As Boolean) As Boolean
Dim blnConfirma As Boolean
Dim strSQL As String
Dim strMensaje As String
[color=#000000]………. Debug.Print “——- INFO AGREGA REG ——-”
[color=#000000]………. Debug.Print “Campos: ” & pstrCampos
[color=#000000]………. Debug.Print “Datos : ” & pstrValores
[color=#000000]………. strSQL = “INSERT into ” & Nombre_Tabla & ” ( ” & pstrCampos & ” )
[color=#000000]………. // VALUES ( ” & pstrValores & “)”
[color=#000000]………. blnConfirma = Execute(strSQL)
[color=#000000]………. If blnConfirma Then
[color=#000000]…………… If mostrarmensaje Then Call MsgBox(“*** Registro actualizado ***”,
[color=#000000]………. // vbInformation, “Actualización de Registro”)
[color=#000000]………. Else
[color=#000000]…………… strMensaje = “No se agregó el registro , *** Verifique con Sistemas ***”
[color=#000000]………….. Call MsgBox(strMensaje, vbCritical, “Agregar Registro”)
[color=#000000]………. End If
[color=#000000]…….Agrega_Reg = blnConfirma
[color=#000000]…….End Function

En el próximo, veremos como se hace una baja y un cambio por SQL.

——————————————
Alfonso Orozco – Mayo 2001
ICQ 41907900

Continuamos con el sistema de conciliación Bancaria, y veremos un ejemplo de cómo podemos evitar tantos formularios.

La base de lo que sigue es algo obvio, pero sin embargo obvio: Casi todos los usuarios están familiarizados con windows. Crear formularios a diestra y siniestra para emular Msgbox e inputbox con iconos/opciones diferentes, es contraproducente.

Al pasar a bancos notamos que solo tenemos 3 datos, de los cuales dos son obligatorios y uno no. Por regla general he visto que a los usuarios les molesta un poco tener una pantalla completa para menos de 4 datos, y a mi me da flojera gastar tiempo y líneas de código en algo que puede resolverse mas simple. Aunque el proceso que veremos se ve bien, y su simplicidad resulta obvia, sugiero no usarlo en tablas con mas de 4 campos “visibles al usuario”, por visibles al usuario me refiero a los campos que ellos pueden modificar.

[color=#FFFFCC]BANCOS

[font=Courier New]NOMBRE[color=#000000]………TIPO[color=#000000]………..LARGO[color=#000000]……….INDICE[color=#000000]……..UNICO[color=#000000]………..NULO
——————————————————————————————————-
BCO_CVE[color=#000000]………Carácter[color=#000000]…….10[color=#000000]………….Sí[color=#000000]…………Si[color=#000000]…………..No
BCO_NOM[color=#000000]………Carácter[color=#000000]…….20[color=#000000]………….No
BCO_NOTA[color=#000000]……..Carácter[color=#000000]…….60[color=#000000]………….No[color=#000000]…………No[color=#000000]…………..Sí

Describe[color=#000000]…….De que[color=#000000]………Cuantos[color=#000000]……..Vamos a[color=#000000]……..Es único o[color=#000000]…..Es
el campo[color=#000000]…….tipo son[color=#000000]…….espacios[color=#000000]…….buscar por[color=#000000]…..o puede[color=#000000]……..obligatorio
[color=#000000]……………los datos?[color=#000000]…..va a usar?[color=#000000]…..este valor?[color=#000000]….repetirse[/font]

Debido a su tamaño puedo asegurar que cualquier módulo ABC de menos de 5 campos visibles puede gestionarse sin usar textbox, lo que nos evita bastante código. Incidentalmente, los ABC que cumplen estas condiciones pueden integrarse en una parte pequeña de otra pantalla, porque si tenemos un reporte rápido para ver el “catálogo”, será mas intuitivo ver el reporte que los textbox. O peor aun, que crear un grid. Ustedes y yo hemos visto programas que usan grids hasta por las orejas, en lugar de un solo reporte bien estructurado. Y Para imprimir el grid siempre se tiene que hacer el reporte de todos modos.

Así que considerando los otros módulos o Tabs, crearemos nuestro control de ABC en la parte derecha del que dice cuentas.

[color=#FFFFCC]Taller:

1. Cambiar la propiedad Caption del Tab Bancos a – Borrar –

2. Seleccionar el tab cuentas y crear un frame al que llamaremos frabancos, con un caption que diga “Maestro de bancos”

3. Crearemos dentro de Frabancos un listbox y seis commandButton con los mismos caption que usamos en el tab de tipos de movimientos, se llamarán LstBancos ( Con sorted true ), y los seis botones con index de 0 a 5.

Tip: Sugiero copiar y pegar lo de tiposmov, y siolo modificar index y nombre de los controles despues de eliminar textbox. Ojo con decir que no cuando nos pregunte si quieremos hacer un arreglo.

Si hicieron el taller, notarán que resulta obvio que no sabemos cuanto espacio vamos a necesitar para el frame de cuentas, asi que sugiero que antes de hacer el código de bancos hagamos solo el diseño de la pantalla de cuentas.

Considerando que:

[color=#FFFFCC]CUENTAS_B (la b es notacion de cuentas bancarias)
[font=Courier New]
NOMBRE[color=#000000]………TIPO[color=#000000]………..LARGO[color=#000000]……….INDICE[color=#000000]……..UNICO[color=#000000]………..NULO
——————————————————————————————————-
CTAB_CVE[color=#000000]………Carácter[color=#000000]……03[color=#000000]………….Sí[color=#000000]…………Si[color=#000000]…………..No
BCO_CVE[color=#000000]……….Carácter[color=#000000]……10[color=#000000]………….No
CTAB_SUC[color=#000000]………Carácter[color=#000000]……30[color=#000000]………….No
CTAB_NCHEQ[color=#000000]…….Carácter[color=#000000]……60[color=#000000]………….No[color=#000000]…………Si
CTAB_TITU1[color=#000000]…….Carácter[color=#000000]……10[color=#000000]………….No
CTAB_TITU2[color=#000000]…….Carácter[color=#000000]……10[color=#000000]………….No[color=#000000]…………Si
CTAB_TITU3[color=#000000]…….Carácter[color=#000000]……10[color=#000000]………….No[color=#000000]…………Si
CTAB_FEAPE[color=#000000]…….Carácter[color=#000000]……10[color=#000000]………….No
CTAB_SMIN[color=#000000]……..Carácter[color=#000000]……15[color=#000000]………….No
CTAB_FEBAL[color=#000000]…….Carácter[color=#000000]……10[color=#000000]………….No[color=#000000]…………Si
CTAB_NOTA[color=#000000]……..Carácter[color=#000000]……60[color=#000000]………….No[color=#000000]…………Si
CTAB_RESP[color=#000000]……..Carácter[color=#000000]……10[color=#000000]………….No[/font]

Quiero que pongan atención que los campos titular1 a titular 3, y el responsable, son del mismo tamaño. Esto se debe a que deben hacer referencia a los usuarios de la tabla usuarios, que veremos después.

Fijense que el campo de bancos se llama BCO_CVE y no CTAB_BCO, porque realmente estamos usando un dato de bancos. Obviamente el largo y tipo del campo en las dos tablas, bancos y cuentasb, deben ser iguales, pero no necesariamente los indices.

[color=#FFFFCC]Taller:

Usaremos un Frame llamado fracuentasb, un listbox sorted true ( lstcuentasb), seis command buttons y los textbox necesarios con la propiedad maxlength fijada al largo, con arreglo de index de 0 al que haga falta.

Una vez hecho esto la pantalla debe verse mas o menos así:

Pantalla del sistema de conciliaciones (2)

Si no la tienen, les envío en el siguiente correo el archivo conc02.zip, donde viene el proyecto en Visual 5. SP3. Si no ven la pantalla, está en images/conc03.gif

El secreto de como evitar pantallas es muy simple. Veamos como sería en un sistema normal la pantalla de alta de bancos:

Pantalla típica de alta de bancos

Supongo que la idea de esas pantallas es que al dar unclick en aceptar se guarden todos los cambios, y desactivar cambios desagradables en algunos casos. Vamos a ver un ejemplo de pedir esos datos sin formulario. Recuerden solamente que mas de cinco datos MODIFICABLES ya no es práctico, y si es ese el caso, casi seguramente ya hay ligas adicionales a mirar.

[code]private sub pidedatosbancos
‘ creamos tres variables para los datos que queremos.
dim strClave as string, strNombre as string, strNota as string
do