RojoIntenso.net - Técnicas RAD

Notas de Programación Multiusuario

Fri, 03 Apr 2009 20:58:37 +0000

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:

Salvo en casos excepcionales, solo un archivo de base de datos estará abierto a la vez. Ejemplo, al guardar en bitácora.
El usuario MAESTRO será el único autorizado para dar altas o cambios de usuarios del sistema, incluyendo niveles de acceso.
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.
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.
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.
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.
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.
Los procedimientos y menús deben ser lo mas modulares posibles y reutilizables por otros sistemas.
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.
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.
El programa debe permitir modificaciones-adaptaciones para cumplir con las necesidades de empresas del mismo giro, pero con el mismo código..
NO DEBE PERMITIRSE BAJAS FISICAS O LOGICAS DE INFORMACIÓN QUE PONDRÍAN EN PELIGRO LA INTEGRIDAD RELACIONAL DEL SISTEMA
Se debe dar prioridad a Legibilidad sobre eficiencia de código, y a bajo consumo de memoria sobre velocidad.
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.
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
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.

Ejemplo de Licencia de Librería

Fri, 03 Apr 2009 20:33:21 +0000

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.

Sobre los modelos

Fri, 03 Apr 2009 20:31:05 +0000

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:

Entidades
Procesos
Receptores de datos ( NO NECESARIAMENTE Tablas o bases )
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.

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

Exportar de VB a XLS

Fri, 03 Apr 2009 20:24:00 +0000

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

Acceso a Datos 16: La esencia de RAD

Fri, 03 Apr 2009 07:01:38 +0000

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 images/antes.zip, el modificado para ser RAD está en images/despues.zip; 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

15: Bajas por SQL Pros y Contras.

Fri, 03 Apr 2009 07:01:25 +0000

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

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

Pero la orden en SQL es muchisimo mas simple:

db.execute("DELETE * from ALUMNOS where EDAD>18")

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.

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

'Ejemplo:

'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

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

Acceso a Datos 14: RAD Aplicado a diseño de Tablas

Fri, 03 Apr 2009 07:01:10 +0000

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í

Tablas en inventario.mdb[color=#000000].............Sugerido
----------------------------------------------------------------------

CAT_EQUIPO[color=#000000]...................

EQUIPO

CAT_PLANTA[color=#000000]...................

PLAZA

CAT_PROVEEDORES[color=#000000]..............

PROV

CAT_USUARIOS[color=#000000].................

EMP_PLAZA

MOVIMIENTOS[color=#000000]..................

MOV_EQUIPO

RECEPCIÓN DE EQUIPO[color=#000000]..........

REC_EQUIPO

[color=#FFFFCC]Access Comentarios

[color=#FFFFCC]Bien

Muy bien por las mayúsculas
Muy bien con el prefijo Cat en las tablas.. pero eso es en el código. Si todas empiezan con CAT, el prefijo resulta mucho menos util.
EXCELENTE las referencias a campos de otras tablas como debe ser, ejemplo, referirnos siempre a USUARIOS como USUA_CVE en lugar de EQUIPO_USUA
Los nombres son claros. No hay nada tipo EQUI02 EQUI03 .... Todo son Catálogos ABC, pero el largo de 10 es excedido.

[color=#FFFFCC]Access Mal

Los acentos. Algunos campos tienen mayúsculas y la tabla recepción lleva acento. No todos los manejadores los soportan, evitarlos y las ñ Tambien.
USUARIOS como nombre de tabla. Un programador que vea el código puede confundirse porque USUARIOS suele usarse para derechos. EMP_PLAZA Indicaría que esta hablando de empleados de algun lugar, que a su vez reciben los equipos.
MOVIMIENTOS como nombre de tabla. Muy largo y puede referirse a cualquier cosa. Movimientos de que?
Los nombres de los campos en varios casos exceden los 10 caracteres. Puede causar problemas si hay que migrar después.

[color=#FFFFCC]Ajustes menores

En este caso hay oficinas, no solo plantas. Usar el nombre plaza permite usarlo en entornos comerciales y no solo industriales.
Proveedores no se llama Proveedores de equipo que sería lo obvio a primera vista, porque así puede controlarse desde clips hasta material de venta.
Uno de los campos de equipo, se llama MODLEO, para esto sirven los modelos fisicos, podemos detectar errores de dedo mas rapido.

[color=#FFFFCC]Access Sugerencias

El programa llevará control de Equipo.. pero podría controlar insumos o lo que sea, sugeriría cambiar Equipo por MATERIAL.
Si vamos a llevar control de equipos.. porqué no está el campo EQUIP_CVE en movimientos?
En algunos casos la descripción es DES ( PLANTA_DES ), en otros descrip ( EQUIP_DESCRIP ), y en otro MOV_OBSERV. Sugiero pasar todo a TABLA_DESC.
Con Nombre pasa lo mismo en PROVE_NOM y USUA_NOMBRE. Por lo menos va a ser mas facil acordarnos de como se llama el campo si unificamos criterios.
Yo pondría el nombre del contacto en proveedor, y un campo de descripción/comentario en recepción de equipo.
El nombre de la base, inventarios2, es largo y poco claro. Inv_Equipo sería mas claro creo yo.
Si se va a mandar equipo de una plaza a otra, en la tabla de movimientos pondría los campos de plaza origen y plaza destino. Obvio que en movimientos en la misma plaza, serian iguales.
Para simplificarnos la vida, manejaría EQUIP_CVE como autoincremental numérico y unico.

Es muy recomendable trazar en papel o en Data Architect una relación de dependencias de las tablas, para poder ver a simple vista que es que, y que depende de qué. Aqui pego una imagen que tomé del Data Architect, con las relaciones ( le puse el campo de EQUIP a MOVIMIENTOS y quité los acentos). En un manejo mas formal, debería de poner la fecha del modelo, pero por lo general basta con imprimirla y tenerla a la mano.

Si se fijan en la dirección de las flechas todas apuntan en la misma dirección y no se cruzan. Todos pueden saber que depende de que, en este caso PLANTA sería la mayor en jerarquía, y recepción la ultima.

Si alguien desea que veamos algun caso en particular, manden su base de datos o estructura, preferentemente vacia, a webmaster@ojosabiertos.org, y por el espacio no se preocupen, tengo 250 mb en la cuenta de correo.

-----------------------------------
Alfonso Orozco - Mayo 2001
ICQ 41907900

Acceso a datos 13 : Elección del formato de datos/soporte físico

Fri, 03 Apr 2009 07:00:55 +0000

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:

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

Acceso a Datos 12: Altas por SQL / Los dos procesos SQL

Fri, 03 Apr 2009 07:00:42 +0000

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 www.download.com, 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,

http://rojointenso.net/mybb/?p=3723

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

Acceso a datos 11: Como evitar tantas pantallas

Fri, 03 Apr 2009 07:00:30 +0000

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

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

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)

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

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

Acceso a Datos 10: Mas de Principios RAD Aplicado a Visual Basic

Fri, 03 Apr 2009 07:00:00 +0000

[color=#FFFFCC]Mas de Principios RAD

En ocasiones anteriores hemos mencionado algunas cosas sobre RAD (diseño rápido de aplicaciones). Sin embargo, hace un mes mas o menos me pasó algo curioso, me contrató una empresa para hacer un trabajo free-lance referente precisamente a conciliaciones bancarias en una serie de programas realizados en Visual Basic 4.0 a 16 bits, utilizando el SDE, que viene siendo una especie de sistema para cambiar Clipper a Windows, pero menos logrado que Visual Objects o que el mismo Five Win.

Creo que es importante mencionar algunas cosas que me di cuenta que para mi eran obvias, pero nunca las había puesto por escrito, y permitirán entender mejor las lecciones que siguen; estoy trabajando en el motor de ayuda para que lo puedan consultar fuera de linea.

1. Debe tratar de tenerse un máximo de diez formularios en todo momento; en raras excepciones 20. Los que trabajaban conmigo en Nieto recordarán que el sistema de Visual que hice para todos los sistemas era de un solo formulario por programa, y el nuevo suministros era de mas de 30. Ustedes saben lo que provocaba en facilidad de uso y control de versiones.
2. No usar controles ajenos a Microsoft en la medida de lo posible, por muy bonitos que sean. Evitan reusar el código, y posiblemente hay algo mas moderno y mejor de Microsoft. Citando otra vez a Nieto, recuerden el problema de los dirvers de Merant para accesar DBFs en lugar de Utilizar ADO.
3. En la medida de lo posible, traten de liberar muchos cambios chicos seguidos que un cambio grande con todos; la curva de aprendizaje del usuario es mejor, y además permite corregir errores que no nos hubieramos dado cuenta.
4. En el desarrollo rápido de aplicaciones, debe tratar de burocratizarse lo menos posible el diseño. En muchos lugares el analista es el jefe del programador, o es un analista diferente al que hace el código, pero ... es tremendamente frustrante, y tonto encontrar al 80% del trabajo un error garrafal de diseño que uno tiene que arreglar rehaciendo todo de cero.
5. Si tienen un empleado o usuario Beta, o documentan código para otro uso, traten de comentar el código; me refiero a No decir : Esto simplifica el código, sino a decir que cambia de una versión a otra.
6. En la medida de lo posible, deben tener una representación del modelo físico en lugar del modelo lógico; el modelo físico es mucho menos suceptible a confundir procesos con personas. En el modelo lógico pueden encontrar el proceso Usuarios, cuando este es una persona.

[color=#000000].........6a) Usando el modelo físico, si ven facturas lo mas probable es que se refieran a facturas, pero en un modelo lógico se pueden encontrar con que facturas se refiere a entradas de cuentas por pagar o por cobrar, y nada que ver con facturas.

7 Como regla general, si una Tabla tiene menos de 100 registros, NO NECESITA INDICES.
8 El número de indices debe de ser razonable. Alguno de ustedes recuerda aquellos programas originales de clipper, o el Sae de ASPEL que tenían indices hasta en la sopa? He manejado bases de datos de 700 megas con 4 indices, pero he visto sistemas con archivos de 10 registros y siete indices, y programadores que se quejan de que con Clipper/foxpro es dificil abrir mas de 15 indices a la vez.(¿?)
9 Los procesos ABC deben estar en una sola pantalla del mismo catálogo. Los cambios y altas son muy parecidos, no tiene caso tenerlos en otra.
10 Los reportes de preferencia deben estar en un archivo aparte TODOS; esto facilita usar un solo formulario de impresion de reportes, o hacer cambios rapidos a todos los reportes.
11 Las pantallas para fijar acceso deben ser congruentes. Tener 10 pantallas para pedir diferentes tipos de acceso podría hacerse con una forma general bien hecha.
12 Puede usarse una función global de contraseñas; para solicitar en diferentes lugares del programa, en lugar de tener tres formularios diferentes con distinto texto y contraseña Hard Coded.

Ahora les voy a describir el sistema principal de esa empresa. Era un equivalente a SAE, programa administrativo de control de chequeras, producción, bancos, insumos , cuentas por pagar y cobrar, busqueda de clientes , proveedores , etc etc etc.

Un total de 220 formularios MAS archivos FRX, haciendo una relación de que era que, resultó que 175 correspondían a busquedas, grids y reportes de ABC, que se podían reducir a 65. Además manejaban reportes casi idénticos para cuentas por cobrar y por pagar, pero en diferentes formularios. Y por ultimo... tenian que correr en maquinas con 256 MB de ram por la memoria disponible; programados por Accesos a funciones SDE y algo de RDO. ( esto lo vi en el año 2000 pero seguro que hoy por hoy hay programas equivalentes)

Y lo peor es que este tipo de programas no son nada infrecuentes. Como dato general, teniendo la estructura de base de datos, la conciliación bancaria quedó en dos tardes de trabajo, me embolsé 400 dolares, y les presenté una propuesta para pasar todo a ADO por 1000 dolares con una entrega a un mes.

El estimado que tengo es que ese sistema se puede hacer en 30 formularios, y eso porque controla una cantidad de procesos que tiene que ver con barcos y bodegas. Que creen que sea mas facil y rápido, controlar 30 formularios o 220 ?

Acceso a Datos 09: Altas y Bajas: (1) Sentido Común

Fri, 03 Apr 2009 06:59:45 +0000

Algo que debemos considerar siempre es la posibilidad de que se vaya la luz a media operación, asi que un sistema bien diseñado debe tener el menor numero posible de tablas y bases abiertas, o les pasa lo que sucede con los tristemente célebres programas de ASPEL, COI, NOI, y SAE. A los que conocen mi trabajo recordarán que cuando se va la luz los sistemas se recuperan de manera transparente.

Para poder conseguir esto, lo mejor es abrir y cerrar las bases y/o tablas cada operación excepto en procesos intensos, y rara vez abrir a la vez dos tablas. Claro que ayuda tener no breaks fiables en la medida de lo posible.

Sin embargo, eso está fuera del alcance de este tema, aunque mas adelante lo veremos PARCIALMENTE cuando veamos ADO.

Antes de codificar, vamos a ver a grandes rasgos que pasa cuando alguien da un alta de datos en una tabla, DE LO QUE SEA:

[color=#FFFFCC]PASOS PARA DAR UN ALTA

[color=#000000]....1. Deshabilitar las opciones de altas, bajas y cambios en los menús para evitar problemas por doble click. Habilitar opciones de cancelar y guardar cambios.
[color=#000000]....2. Revisar si ya existe el dato que queremos dar en esta tabla.
[color=#000000]....3. Si existe

Avisar y restablecer botones
Cancelar el proceso

[color=#000000]....4. Verificamos que existan los datos obligatorios, TODOS.
[color=#000000]....5. Si faltan

Avisar
Llevar a donde falta el dato
Cancelar el proceso

[color=#000000]....6. Revisar si hay datos duplicados que no deban serlo ( que en la columna unico de nuestra tabla tengan si )

Si hay avisar, llevar, restablecer botones y cancelar proceso

[color=#000000]....7. Si todo es correcto, guardar. ( Si algo falla preferentemente interceptar )
[color=#000000]....8. Restablecer botones y refrescar pantalla

[color=#FFFFCC]PASOS PARA DAR UNA BAJA

[color=#000000]....1. Deshabilitar las opciones de altas, bajas y cambios en los menús para evitar problemas por doble click rapido.
[color=#000000]....2. Revisar si el dato que queremos ya esta seleccionado
[color=#000000]....3. Si no

Pedir que se seleccione
Restablecer botones
Cancelar el proceso

[color=#000000]....4. Verificamos si esta ligado a otra tabla, si es así, avisamos que no se puede borrar (no podemos borrar un banco si tiene cuentas, por ejemplo)
[color=#000000]....5. Continuamos SOLO si ya no hay datos ligados
[color=#000000]....6. Si procede lo demas, preguntamos si queremos borrar, dando por default no.
[color=#000000]....7. Si deciden borrar, borrar
[color=#000000]....8. Restablecer botones y refrescar pantalla

Para hacer esto es necesario tratar de convertir todo a código. Es importante mencionar que no todos los pasos se hacen con el mismo botón en altas, solo el primer boton corresponde a altas, y todo lo demas al boton de guardar cambios.

Si se fijan todos los pasos anteriores son elementales. Vamos a referirnos ahora a el código de tiposmovimentos, específicamente de sus botones, lo que nos lleva al evento click de cmdtiposmov.

Nota: Cuando Comenté que se usaran las propiedades index, la finalidad es simplificar la programación. Esto se debe a que si no manejamos un arreglo de botones , tendriamos seis eventos de controles DIFERENTES, y además de tener que repetir código, sería dificil de mantener. De esta manera usaremos un solo procedimiento, para altas, bajas y cambios por cada tabla.

Veremos un ejemplo, que en lo personal es mi base para la mayoría de las veces, porque con hacer unas cuantas modificaciones, terminamos un módulo ABC completo en cuestión de minutos. A varios que me conocen, les consta que en una hora puedo sacar 6 o 7 módulos completos con reportes, aunque no se suele necesitar esa velocidad.

Después de ver el ejemplo veremos varios de esos procesos obvios, son los que tienen un link dentro del documento.

Vean este ejemplo código de un programa de productos, noten que hay procesos obvios por el nombre (con un link a donde está el código) pero que no son ordenes validas, por ejemplo, resaltacontrol. El ejemplo incluye también el manejo de cambios pero eso lo veremos en tres correos o mas junto con las ordenes que faltan, por ejemplo, la explicación de que es DataClass. Si Usan ahora es bajo su propio riesgo.

NOTA: Las líneas que empiezan con // deben ir al final de la línea anterior. Mas adelante subiré el código en el proyecto, pero necesito que lo vean ahora por referencia.

[code]Private Sub cmdProd_Click(Index As Integer)
Dim strprov As String
Dim strsubc As String
cmdProd(Index).Enabled = False
Select Case Index

[color="#FFFFCC"]Case 0: ' altas

' tomamos proveedor
strprov = lstProv.List(lstProv.ListIndex)
If strprov = "" Then

Acceso a Datos 08: Un poquito de SQL

Fri, 03 Apr 2009 06:59:32 +0000

Antes de proseguir, voy a pedir a los que no han leído los correos anteriores, que vean las páginas

http://rojointenso.net/mybb/?p=6376

datos03 que contiene las diferencias entre ADO y DAO, y

http://rojointenso.net/mybb/?p=4012

datos06.htm que trae ejemplos de cómo accesamos a los datos en DAO.

Lo que sigue va a suponer que ya lo leyeron. A grandes rasgos DAO era una forma de accesar datos que diseñó Microsoft, que evolucionó después en ADO.

Tipo de Acceso: [color=#FFFFCC]DAO

[color=#FFFFCC]Ventajas:

Sistema de búsqueda muy robusto
Permite modificar tablas dinámicamente

[color=#FFFFCC]Desventajas:

Lentitud relativa

Tipo de Acceso: [color=#FFFFCC]ADO

[color=#FFFFCC]Ventajas:

Rapidez
Muy portable

[color=#FFFFCC]Desventajas:

Deben seleccionarse los drivers con cuidado
No permite modificar dinámicamente tablas SQL SERVER (con ADOX si es posible)
Sistema de búsqueda No SQL menos poderoso.
Mucha funcionalidad extra que no se necesita ( objetos stream y record )

Sin embargo, aunque ADO y DAO son muy parecidos, surge mucho el problema de elegir cual es mejor. La respuesta es simple. ADO es mejor, y si necesitamos por algo en especial las ventajas de DAO, podemos usar los dos en un solo sistema, en la actualidad lo normal es usar consultas SQL desde código Visual Basic para suplir las desventajas de ADO en cuanto a motor.

Técnicamente es posible hacer un programa DAO estructurado de tal manera que podamos hacerlo ADO sin esfuerzo. Lo veremos ya que programaremos en DAO, y finalmente haremos ajustes que realicen el cambio. Esto es característico de los buenos programadores. No Necesito decir nombres, pero todos conocemos a programadores que se tardan semanas, a veces meses y años, en cambiar sus sistemas en metodologías de acceso, simplemente porque no están bien estructurados. En otro correo hablábamos de los programas ABC, es decir, los procesos de altas, bajas y cambios de todos los módulos de un proceso determinado. En el correo 06, vimos que era posible accesar a los datos a través de un recordset, o conjunto de resultados, que se transformaban, ordenaban y modificaban en base a una sola cadena SQL. Aunque más adelante veremos con mas detalle SQL, vamos a ver muy rápidamente lo que es la sintaxis de la apertura de recordsets.

1. Debe usarse en DAO un openrecordset.
2. Toda consulta de registros empieza con un "select", seguido por el nombre del campo o campos a consultar, terminando con una orden from que va a decir de donde es la tabla a usar. El orden de los campos en la declaración, será el orden en los resultados. Puede sustiuirse el nombre de los campos por un asterisco, pero esto llama todos los campos, no solo los solicitados.

Select NOMBRE,DIRECCION from ALUMNOS
Select DIRECCION,EDAD from ALUMNOS

1. Podemos filtrar con la cláusula where

Select NOMBRE,TELEFONO from ALUMNOS where TELEFONO=5678-1234
Select TELEFONO,EDAD from ALUMNOS where EDAD > 18

1. Y podemos ordenar en base a una cláusula order by.

Select NOMBRE,APELLIDO from ALUMNOS order by APELLIDO
Select * from ALUMNOS where EDAD <18 order by EDAD

Lo interesante es que el secreto de SQL es mantener las ordenes sencillas, no complicadas, y sobre todo evitar usar el asterisco en lugar del nombre de los campos. Esto se debe a que en una tabla con muchos campos, es más eficiente cargar solo los necesarios y usar asterisco los carga todos.

Una vez que sabemos que consultar, tenemos que saber como revisar si hay o no resultados a nuestra pregunta. ADO y DAO nos ofrecen dos métodos, uno usando la palabra clave nomatch que no entra en el espíritu de SQL, y la orden según SQL.

Vamos a suponer que pedimos los alumnos mayores a 18 años en una escuela primaria. Casi seguramente no hay resultados, no?

Un ejemplo de código sería:

[code]Dim db as DAO.database
Dim rs as DAO.Recordset
Set db= OpenDatabase("alumnos.mdb") ' esto abre la base de datos en Access
Set RS= db.openrecordset("Select * from ALUMNOS where EDAD <18 order by EDAD") abre
With rs

Acceso a Datos 07: Principios RAD

Fri, 03 Apr 2009 06:59:19 +0000

Una explicación a manera de disculpa

Aunque no ha sido mi intención descuidar la lista, han sucedido una serie de detalles fuera de mi control, que me han obligado a hacerlo.

Por un lado, en la empresa que trabajaba desde noviembre, la del viaje a Brasil, estaba demorando los pagos de la nómina, y además cuando vieron el sistema de contabilidad que iba a presentar aquí, mismo que desarrollé hace años para un cliente, me salieron con que era propiedad de la empresa e iba a ser obligación de mi parte usarlo y adaptarlo para uno de sus clientes, aunque yo lo había hecho desde 1995.

Todo el proceso estructurado se fue a la basura, y he decidido a partir de hoy continuar con conciliaciones bancarias, porque puede usar mucho de los principios que vimos antes de contabilidad. Aunque el sistema de contabilidad es perfectamente válido y razonable, no pienso hacerle el trabajo a nadie que me trate de mal modo, sin cortesía, y que además demora los pagos.

Por otra parte los procesos legales que mencione antes, han quedado a medio resolver, solo queda pendiente el del derecho de uso de los programas que realicé en 1996 para las automotrices, y aunque ya probamos el uso sin permiso, y con premeditación y agravantes, aun estoy esperando la sentencia del juicio, misma que debe ser favorable y no pasar de unos tres meses.

Como es natural, el tiempo necesario para dar seguimiento a las diferentes instancias ha sido considerable, pero gracias al movimiento de la empresa de host, www.hostchess.com, puedo tomarme todo con cierta tranquilidad.

Sobre el viaje a Argentina y España, dependen de la terminación de los juicios, ya que por ahora debo estar aquí vigilante de mi \"centímetro cúbico de suerte\".

Así que en resumen, volveré al tema de las bases de datos y su acceso, pero ahora desde el ejemplo de las conciliaciones bancarias, donde podremos usar lo anterior.

Saludos, y gracias.

Como ustedes recordarán el manejo de las bases de datos debe basarse en la sencillez, si es complicado no funciona o será muy difícil de aplicar o mantener.

Para crear una base de datos es indispensable tener una idea de lo que vamos a hacer, CONFIAR EN NUESTRO CRITERIO, y ser capaces de simplificar el proceso o modelo hasta que quede en una sola página, por lo general, o un máximo de 4 páginas, sin embargo, el 95% de los sistemas deben caber en una sola hoja.

Cada vez que me refiera a un modelo, sin excepción me voy a referir al modelo físico, NO a las relaciones lógicas. Esto es porque un problema de los modelos lógicos es que al poco tiempo se terminan midiendo peras con manzanas, y en un esquema físico resulta mucho más fácil observar los "colores diferentes", y si se trabaja de manera ordenada, las ventajas del modelo lógico se siguen aplicando.

A partir de hoy usaré bastante seguido el término RAD, Desarrollo rápido de aplicaciones ( rapid applications development ) que es una metodología de trabajo y desarrollo creada por Microsoft, y aplicable sobre todo a su línea NET y VB. Aunque más adelante haremos comentarios sobre RAD, lo que ahora nos interesa es una serie de principios básicos que tienen que ver mucho con la calidad de los programas, su facilidad de uso, y la velocidad de desarrollo, en proyectos de tamaño mediano, aunque es aplicable a procesos chicos y grandes.

[color=#FFFFCC]Principios RAD

1. El programador tiene criterio y responsabilidad. Si hace algo que funciona y se ve bien, se queda.
2. Deben usarse componentes reutilizables, es decir, todo el código debe de ser usable en otros proyectos de ser posible.
3. Los buenos programas usan una sola pantalla de trabajo, y cuando mucho 5 a 10 pantallas o formularios propios. Usar una pantalla MDI con chorro mil ventanitas es molesto para los usuarios, y un infierno para mantener. Es válido usar muchos módulos de código, pero pantallas de trabajo, pocas.
4. El acceso a las bases de datos debe hacerse en una sola función, así si debe cambiarse el modo de acceso o la tecnología, solo debe hacerse modificación en pocos lugares.
5. Los nombres de tablas, campos y registros, deben ser simples, claros y construidos de acuerdo a un esquema predecible.
6. Lo anterior significa cortos, directos y en español. No se vale carta84b.doc por ejemplo.
7. Los programas deben tener mucho sentido común. Es mal programa si se necesita manual para encontrar donde se hace un alta.
8. En un proyecto estándar se usan solo dos bases de datos como mucho. Aquellas que usen mas de tres, deben revisarse prácticamente desde cero.

Una vez que tenemos estos principios básicos, podemos continuar.

La teoría de las conciliaciones bancarias es sencilla. Cuando se realizan operaciones con un banco, cada cierto tiempo este nos entrega cartas de resumen o estados de cuenta de los movimientos más recientes, pero frecuentemente los datos no cuadran, ya sea porque nos cobran de mas, nos pagan intereses, etc.

Una regla práctica a considerar es que cada banco ofrece varios tipos de cuentas, y en ocasiones uno tiene con ellos mas de un servicio contratado.

Otro comentario, es que en la facultad de contabilidad, un maestro nos dio un excelente consejo, que dice "Nunca se debe tener cuentas en solo un banco, o en mas de cuatro". Esto se debe a fines de control, por un lado, y segundo que si falla el único banco que usamos, que hacemos? Tener cuentas en varios bancos permite procesos alternos.

Planteamiento del problema:

Vamos a suponer que nuestro programa lo van a usar en una empresa de 10 personas, para llevar control de tarjetas de crédito, de débito, de cuentas de cheques, y de inversiones y pagarés bancarios a la vista y a plazo fijo, Una de las tarjetas de crédito es usada por el director, y una adicional por el contador, con un numero de tarjeta diferente, pero es la misma cuenta, y hay tres personas autorizadas a firmar en la chequera principal, pero los cheques siempre los firman dos.

Reto RAD: Tenemos una semana para hacer un programa que funcione y lleve ABC, respaldos, restaurar y reportes básicos.

[color=#FFFFCC]Solución:

Empezar a actuar

[color=#FFFFCC]Prediseño:

[color=#FFFFCC]Palabras clave:

Tarjetas, cuentas, usuarios, chequera, bancos, salidas de dinero, entradas de dinero.

[color=#FFFFCC]Tablas necesarias:

Banco
Cuentas
Usuarios
Tarjetas
Movimientos ( entradas y salidas )

Nota: Las chequeras dependen de cuentas de cheques, es decir, no son independientes. Las cuentas tienen una chequera, nunca dos.

[color=#FFFFCC]Organigrama de tablas:

Banco[color=#000000]...[color=#000000]...Cuentas[color=#000000]...<--[color=#000000]...Usuarios
[color=#000000]...|[color=#000000].....................|
Tarjetas[color=#000000].......Movimientos

Antes de continuar, vamos a ver que elementos queremos, sugiero ordenar las tablas por orden alfabético.

Acceso a Datos 06: Acceso a campos y ABC DAO Simple

Fri, 03 Apr 2009 06:59:05 +0000

Antes que empiecen a pensar otra cosa, les recuerdo que vamos por PASOS, mas adelante veremos ADO y bases relacionales, pero creo que aquí viene información interesante para todos.

Para los que no recuerden las diferencias básicas, habíamos dicho antes que DAO era bueno para labores en un solo lugar, su principal ventaja es ser fácil de entender, pero si hay una maquina fuera, por ejemplo, en otra ciudad, es un poco lento de ejecución.

Si bien originalmente DAO era rápido, le faltaba cierta conectividad. En su versión original, nosotros usábamos una propiedad llamada Fields para referirnos al contenido de los datos. En unos dias veremos como funcionaba esa conectividad.

Pongamos como ejemplo la tabla CUENTA.

Habíamos dicho que CUENTA tenia los siguientes campos:

CTA_NUM
CTA_NOMBRE
CTA_TIPO
CTA_DESCRIP
Como pueden ver, todos empiezan con CTA, lo que nos indica fácilmente que todos son propiedades de un mismo conjunto.

Si bien nosotros podemos Abrir la tabla de diversos modos según si usamos DAO, ADO o lo que sea, siempre hay tres formas de referirnos a CTA_NUM, para leer o escribir los datos:

[color=#00FF00]Lectura Tradicional

La primera forma y mas utilizada es :

Para leer
Valor= Cuenta!CTA_NUM

Para Escribir:
Cuenta!CTA_NUM = Valor

Cual es su problema?

En una sola llamada ( un solo campo ) no tiene gran problema, pero si estamos leyendo Dos o mas campos, si.

Ejemplo:
Valor= Cuenta!CTA_NUM
Valor2= Cuenta!CTA_NOMBRE
Pues muy simple, se carga dos VECES Cuenta!, esto significa que dos o mas veces se carga la tabla o su estructura, cuando una sola puede manejarse con otro de los dos métodos.

Otro problema es la dificultad del uso de arreglos.

[color=#00FF00]Lectura ORDINAL (depende del orden)

Para leer
Valor= Cuenta.Fields(0) ' nos regresa CTA_NUM,por ser el primer campo

Para Escribir:
Cuenta.fields(0) = Valor
Problema:

Pues que resulta muy difícil de mantener. A lo mejor en ocho días no nos acordamos que el campo CUENTA.Fields(3) era igual a cuenta!Descrip

No tiene el problema de cargar dos veces, porque puede usarse un bucle with de este modo:

[code]with cuenta