Articulos

Inicio (Articulos)

Tablas

Formularios

Consultas

Macros

Informes

Modulos

Comenzar una aplicación, Planificar y Analizar lo necesario

Como todo gran proyecto, una aplicación, por pequeña que sea, debe planificarse y debe ser analizada para intentar determinar todos los componentes que la formarán en su primera versión.

Este documento solo pretende enseñar a los usuarios de Access ha comenzar bien sus trabajos para evitar, posteriormente, la aparición de sorpresas.

Para ilustrar un método, que a mi hasta ahora me ha ido bastante bien, voy a comenzar con una conversación que se suele tener casi siempre, en el contexto que forman el usuario y el desarrollador:"Oye,  tengo que hacer un programilla y he decidido hacerlo con Access, la verdad es que ya lo he empezado, pero me he atascado y no se por donde continuar."

Este es el momento idóneo para coger un cuaderno y un lápiz, y comenzar a diseñar el prototipo de nuestra aplicación.

Lo Primero que hace falta es determinar las tablas necesarias para la gestión de la aplicación. Normalmente, las tablas necesarias tienen que ver con los conceptos que queremos manejar. Así por ejemplo, si necesitamos crear una aplicación para controlar partidos de Fútbol Sala, posiblemente tengamos que crear una tabla de Árbitros, una de Jugadores, y otra de Partidos. Como se puede observar son conceptos de este deporte, y como mínimo, vamos a necesitar las tablas que representan a estos conceptos.

En otro momento, aprovecharemos para plantear el método idóneo para crear las tablas. En este articulo no vamos a pararnos en esa tarea, sino que vamos a seguir definiendo objetos necesarios para nuestra aplicación.

Bien, pues para cada una de estas tablas, vamos a necesitar un formulario, como es lógico, para llevar el mantenimiento de los registros de datos (altas, bajas, modificaciones y consultas).

Igualmente, para cada una de estas tablas, hará falta un formulario de impresión (solo si queremos seleccionar mediante unos criterios lo que deseamos imprimir).

Hay que tener en cuenta que posiblemente nos haga falta algún subformulario para mostrar datos relacionados. Por ejemplo, en el formulario de partidos, posiblemente nos interese tener varias carpetas, en las que aparezcan los datos generales del partido, los datos del Arbitro, los datos de los Jugadores, y los movimientos o lances que ha experimentado el partido. Este tipo de información, normalmente, se muestra en subformularios vinculados a formularios principales.

En cuanto a los informes, como norma general serán necesarios uno o dos por formulario, asi que podemos contar con una cantidad similar a la de formularios.

Sobre las macros, es difícil plantear cuantas serán necesarias a priori, pero lo que si debemos saber es cuantas opciones de menú incluiremos, y estas se realizan de forma muy eficaz con macros, como ya veremos en próximos artículos.

Igual que ocurre con las macros sucede con los módulos, es difícil plantear cuantos serán necesarios, pero como mínimo hará falta un modulo por concepto, al menos para hacer el tratamiento correcto de los errores, el mantenimiento de las tablas, y el uso de los mensajes para el entorno que el usuario final manejará.

Una vez anotado todo lo que necesitamos: Entre 3 y 4 tablas, 3 y 4 formularios con sus respectivos subformularios, mas o menos los mismos informes que formularios, alguna macro para los automatismos y un poco de código relacionado con la cantidad de formularios, para resolver asuntos puntuales de la programación, ya podemos ponernos manos a la obra y comenzar nuestro proyecto teniendo en cuenta que nuestras tareas primarias serán:

(c) Ángel Pérez Díaz. Todos los Derechos Reservados.