Veamos con un ejemplo real la diferencia de actuación de los tubos de lista y de ficha.

Supongamos una aplicación en la que hacemos albaranes y facturas con una estructura de tablas como la siguiente.

He puesto las tablas de cabeceras de albaranes y de facturas como submaestra de años para aprovechar su código como contador y así que comience a contar en 1 en cada año ( ver articulo )

Así mismo las lineas son a su vez submaestras de las cabeceras correspondientes.

Los campos que tenemos en las tablas cabeceras son practicamente los mismo en una y en otra tabla , al igual que ocurre con los campos de las tablas lineas.

Hagamos ahora los objetos visuales que nos permitirán facturar un albarán.

El proceso general para hacerlo sérá: tenemos una ficha de Cabecera de Albarán de la que

 cuelgan sus históricos Lineas de Albarán. Tomaremos los datos de la CAlbarán y los pasaremos a un ficha de CFacturas. Una vez hecho esto, he de recorrer las lineas de LAlbaranes para hacer lo mismo, es decir, llevarlas a LFacturas pero indicándoles a dichas lineas a qué CFactura pertenecen. Para ello usaremos dos métodos. El primero mediante dos tubos de ficha y el segundo con un tubo de ficha y otro de lista.

Método 1: dos tubos de ficha

Crearemos primero el tubo de ficha para pasar datos desde una Cabecera de Albarán a una Cabecera de factura

Vemos que los capilares que usamos son pocos, no  utilizamos todos los campos, sólamente los que son necesarios para definir la factura al final del tubo, el cliente, el año y el almacén, en caso de ser multialmacén. El resto de los campos de CFactura, se “rellenarán” o bien por contenidos iniciales de los mismos o bien mediante actualizaciones desde las lineas 

Después creamos el tubo de ficha para las lineas en el que usaré dos capilares, el puntero al Artículo y la cantidad de unidades vendidas.

El proceso para facturar un único albarán será el siguiente.

 Proceso en el que ser realiza la facturación de un albarán.

Con lo que obtenemos la factura con sus lineas correspondientes. 

 Método dos: un tubo de ficha para las cabeceras y un tubo de lista para las lineas

Creamos el tubo de lista desde LAlbaranes a LFacturas, con los mismos capilares que los usados en el tubo de ficha. Los cambios irán en el proceso de facturación que se lanza desde la ficha de CAlbarán

Observar que en el post del primer tubo, ya no uso los Set para guardar valores en varialbles locales sino la instrucción de proceso

Guardar ficha, lo que nos permitirá usar un Tubo de lista con inducción. Esta inducción nos permite indicar a todas y cada una de las lineas de factura que se van creando a la salida del tubo de lista a qué ficha de maestro( CFactura) pertenecen.

La inducción hace que cada línea de la factura apunte a la misma cabecera, es decir, introduce el código del registro de la cabecera de la factura en el campo enlazado de los registros de Líneas de Factura.

Cualquiera de los dos métodos es válido. El primero, con tubo de ficha en las lineas, nos permite modificar los registros de salida del tubo, en cambio el tubo de lista no lo permite.

En el caso de tener que facturar varios albaranes en una única factura, podríamos hacer un proceso con origen lista de CAlbaranes para poder lanzarlo como una opción desde una toolbar en una  búsqueda de albaranes presentada en una rejilla multiselección, para ejecutarlo contra los seleccionados. Dividiremos así mismo el proceso en dos. En el primero, ordenamos la lista por Cliente para luego multipartirlo por ese mismo campo. Con ello logramos una “minilista” con cada todos los albaranes de un cliente, y por cada una de esas minilistas, ejecutamos el proceso que los factura.

 Proceso llamador 

Proceso llamado en el que se realiza la facturación de la minilista de los albaranes de un único cliente. Este proceso se repetirá por cada una de las multiparticiones que se obtengan en el proceso llamador.

Como componente final de las tablas tenemos las actualizaciones. Una actualización no permite modificar registros de otras tablas con las que estemos unidos mediante un puntero a singular,es decir, puedo modificar registros de tablas a las que apunte mediante un puntero a maestro, un puntero indirecto o un hermano contiguo.

Su mayor potencia reside en su autorecálculo. Me explico. Supongamos que mediante una actualización, voy llevando a un campo de la tabla Cabeceras de facturas el número de artículos que voy vendiendo. Cada vez que introduzco una linea y pongo las unidades vendidas, al dar de alta la linea se lanza la actualización y me aumenta el contador. Pues bien, si de nuevo entro en la linea y cambio el valor de las unidades, la actualización se rehace, deshace la actualización con el anteriro valor y la rehace con el nuevo. Pero si por alguna causa, borramos una linea, también se recalcula la actualización Y SIN TENER QUE ESCRIBIR NI UNA SOLA LINEA DE CODIGO.

Con  un ejemplo práctico veremos la potencia que encierran las actualizaciones. Supongamos una aplicación para hacer albaranes de venta. Vendemos artículos que tienen un stockaje de almacén y que pueden ir grabados con distintos tipos de IVA. Además queremos llevar en una tabla el IVA repercutido por meses de los distintos tipos de IVA por separado. 

TABLA TIPO TABLA DE DATOS PADRE
CLIENTES Maestro normal con clave numérica -
ARTICULOS Maestro normal con clave numérica -
ALBARANES VENTAS Maestro normal con clave numérica -
LÍNEAS ALBARANES VENTAS Sub Maestro ALBARANES VENTAS
FACTURAS Maestro normal con clave numérica -
LINEAS FACTURAS Sub Maestro FACTURAS

AÑOS. mestra normal con clave numérica

IVA ACUMUALDO. Histórica de Años
A las tablas se han añadido los siguientes campos:

Tabla de ARTICULOS:
IDENTIFICADOR PVP NOMBRE P.V.P. TIPO Numérico LONGITUD 3
IDENTIFICADOR IVA NOMBRE I.VA. TIPO Numérico LONGITUD 1 RANGO MÁXIMO 99 CONT. INI $IVA1$
IDENTIFICADOR PVP-SIN-IVA NOMBRE PVP sin IVA TIPO Fórmula Numérica
FÓRMULA fRedondear( 100 * %PVP% / (100+%IVA%),2 )
IDENTIFICADOR STOCK  NOMBRE Stock TIPO Numérico LONGITUD 2 SIGNO Activado

Tabla de ALBARANES VENTAS:
IDENTIFICADOR FECHA NOMBRE Fecha TIPO Fecha CONTENIDO INICIAL fHoy ()
IDENTIFICADOR NLINEAS NOMBRE Número de líneas TIPO NuméricoLONGITUD 2
Declaramos tres bases imponibles (una por cada tipo de IVA):

IDENTIFICADOR BASE1 NOMBRE Base Imponible 1ª TIPO Numérico LONGITUD 4 SIGNO Activado
IDENTIFICADOR IVA1 NOMBRE I.VA. 1º TIPO Numérico LONGITUD 1 RANGO MÁXIMO 99 CONT INI $IVA1$
Declaramos también otros dos IVA’s más.
IDENTIFICADOR IMP-IVA1 NOMBRE Importe I.V.A. 1º TIPO Fórmula NuméricaSIGNO Activado
FÓRMULA fRedondear(fPorcentaje(%BASE1%,%IVA1% ) )
fPorcentaje (Valor, porcentaje), devuelve el número resultante de aplicar el porcentaje al valor.

Declaramos otros dos campos para calcular el Importe de IVA 2º y del IVA 3º, respectivamente de igual forma que el anterior

IDENTIFICADOR TOTAL NOMBRE TotalTIPO Fórmula NuméricaSIGNO Activado
FÓRMULA %BASE1%+%BASE2%+%BASE3%+ %IMP-IVA1%+%IMP-IVA2%+%IMP-IVA3%
IDENTIFICADOR FACTURADO NOMBRE ¿Facturado?TIPO Booleano (Sí / No) CONTENIDO INICIAL 0
Tabla de LINEAS ALBARANES VENTAS:
IDENTIFICADOR CANTIDAD NOMBRE Cantidad TIPO Numérico LONGITUD 2
IDENTIFICADOR PVP NOMBRE P.V.P. TIPO Numérico LONGITUD 3 CONTENIDO INICIAL %ARTICULOS.PVP%
IDENTIFICADOR IVA NOMBRE % I.V.A. TIPO Numérico LONGITUD 1 CONTENIDO INICIAL %ARTICULOS.IVA%
IDENTIFICADOR IMPORTE-SIN-IVA NOMBRE Importe sin Iva TIPO Fórmula numérica SIGNO Activado
FÓRMULA %CANTIDAD% * %PVP%
IDENTIFICADOR IMPORTE-DEL-IVA NOMBRE Importe del Iva TIPO Fórmula numérica SIGNO Activado
FÓRMULA fRedondear(fPorcentaje(%IMPORTE-SIN-IVA%, %IVA%))
IDENTIFICADOR IMPORTE+IVA NOMBRE Importe con Iva TIPO Fórmula numérica SIGNO Activado
FÓRMULA %IMPORTE-SIN-IVA%+%IMPORTE-DEL-IVA%
La tabla FACTURAS tiene la misma estructura que la de ALBARANES VENTAS, a excepción de los campos NLINEAS y FACTURADO, que no los tiene.

TABLA AÑOS: nos quedamos con el campo código y borramos el campo nombre y los índices NOMBRE, PALABRAS Y TROZOS. Esta tabla, en la que sólo vamos a llevar los años, podemos cargarla de datos con un proceso llamado desde el AUTOEXEC-ON-INIT que tendrá la siguiente estructura

TABLA IVAREPERCUTIDO. Tendrá los campos

TRIMESTRE 1 IVA1: numérico , longitud 4 con 2 decimales y signo

TRIMESTRE 2 IVA1: numérico , longitud 4 con 2 decimales y signo

TRIMESTRE 3 IVA1: numérico , longitud 4 con 2 decimales y signo

TRIMESTRE 4 IVA1: numérico , longitud 4 con 2 decimales y signo

En estos campos llevaremos los IVAS repercutidos por trimestre, para las bases imponibles que correspondan al IVA del tipo 1.  Para los otros tipos de IVAS no tenemos más que hacer otros tantos campos del mismo tipo que el anterior, cuatro por cada tipo

La estructura de tablas queda como sigue

Para tener guardados los valores de los IVAS usaremos tres varialbles globales en disco, de tipo numérico y con longitud 3 y dos decimales.

Para guardar los datos generales de la empresa tenemos dos opciones, o bien usar también variables globales en disco en las que iremos guardando los datos de la empresa, como razón social, NIF, domicilio, código postal, población …. así como un objeto visual tipo dibujo para el logo de la empresa usado en los albaranes o las facturas u otra opción que suelo usar y que es crear una tabla llamada CONFIGURACION en la que se crean los diferentes campos que necesite para definir los datos generales de la empresa, incluidos uno o varios campos objeto dibujo en los que guardar distintos logos.

Con ella, nos evitamos tener que tocar con le vDeveloper un objeto dibujo si la empresa cambia de logo, por ejemplo. Para usarla desde las tablas de las cabeceras de Albaranes o Facturas, simplemente, hacemos un puntero a maestro en cada una de ellas a la tabla configuración, con lo que tenemos acceso a todos los campos sobre todo a la hora de imprimir los informes.

Para rellenar inicalmente los valores de la única ficha de esta tabla, podemos lanzár un proceso llamado desde el AUTOEXEC-ON -INIT que tenga las siguientes lineas

En este mismo proceso podríamos controlar si se ha dado valor a al menos una de las variables globales donde se guardan los IVAS y mostrar el formulario de Configuración en el que tendremos los controles de edición de las variables.

Al mismo nivel que Cargar lista->CONF…..                     

añadimos

if $IVA-1$=0

cargar lista , CONFIGURACION, CODIO

seleccionar ficha por posición->1

modificar ficha seleccionada con formulario, CONFIGURACION

Vayamos con las primeras actualizaciones. Desde la tabla de Lineas de facturas haremos actualizaciones a los campos donde guardamos las distintas bases imponibles, dependiendo del valor del IVA que se aplique al artículo de la linea. Para ello vamos a la carpeta de actualizaciones e insertamos una nueva. Toda actualización necesita un puntero a una ficha para poder actualizar un valor de la tabla apuntada con un valor de un campo de la tabla origen. En este caso, tenemos el puntero a maestro desde la tabla Lineas de Facturas a la tabla Cabeceras. Usaremos este puntero para actualizar las tres bases imponibles, dependiendo del tipo de IVA que se haya usado para la linea.

Para ello usaremo la fórmula condición para modificar. En el caso editado de la base 1, si el iva de la lineas es igual al guardado en la variable IVA 1 lanzaremos la actualización, modificando el campo BASE1, del modo acumular ( sumar a lo que ya había ) lo que está guardado en el campo IMPORTE SIN IVA.

Para el resto de los campos BASE, lo único que variará será la condición de modificación además del campo a modificar.

Si borramos, o modificamos una linea afectando el valor del campo IMPORTE SIN IVA la actualización, ella sóla y sin programar nada más, se encargará de corregir los datos anteriores y salvaguardar los nuevos

Hagamos ahora una actualización a través de un puntero a tabla de datos indirecta real. 

En la tabla Cabeceras de Facturas creamos un puntero indirecto a la tabla IVAS Repercutidos a través del índice de clave única AÑOS  de esta última tabla, resolviendo el AÑO del origen que el AÑO del destino, y activando el flag Dar de alta si no existe por si es la primera factura de un año determinado que introducimos y por tanto en la tabla IVAS Repercutidos aún no hay creado un registro para ese año.

Sólo nos queda lanzar una nueva actualización a través de este puntero para que nos lleve los ivas repercutidos en los trimestres adecuados de cada año.

 Para ello creamos una nueva actualización a través del puntero indirecto.La haremos para el primer trimeste del IVA 1.

La condición será que el trimestre de la fecha sea el 1 y actualizaremos el campo TRIMESTRE 1 IVA 1 con lo que haya guardado en el campo IMP-IVA 1  de la tabla Cabeceras de facturas.

Lo mismo haremos ,cambiano la condición para los diferentes trimestes e IVAS.

Podríamos también hacerlo para los doce meses de cada año. Sólo tenemos que hacer 12 campos por IVA y montar las actualizaciones de la misma forma.

Si tenemos también implementada a parte de compras en nuestra aplicación, podríamos llevar el IVA soportado en la misma tabla y llevar desde la Cabecera de Facturas de Compra todos los IVAs soportados por trimestre o por meses de cada año, y a la vez un campo fórmula en el que nos calculara la diferencia entre el soportado y el repercutido.

Como hemos visto, con las actualizaciones y los punteros y sin escribir ni una sola linea de código, hemos hecho toda la labor, todo en la parte izquiera del vDeveloper. Combinando toda la potencia de los componentes de las tablas con un buen análisis del problema, tenemos el 90% de la aplicación hecha, a falta de hacer los objetos visuales y de resolver cosas que Velneo no tiene implementadas de forma tan directa pero que haremos con los procesos.

El tercer elemento de una tabla son los triggers o eventos de tablas.

Con ellos vamos a poder lanzar procesos que se ejecutarán siempre con origen una ficha de una tabla. Van a sernos muy útiles a la hora de hacer comprobaciones, de modificar valores de campos dependiendo de las condiciones que establezcamos…. además se dá la ventaja de que tenemos la seguridad de que siempre se ejecutan pues no dependen de una pérdida de foco o de que el usuario haya pulsado un determinado botón.

Los eventos de tablas o triggers son de tres tipos: anteriores a , internos a y posteriores a.  A su vez se pueden lanzar desde tres sitios distintos: en un alta, en una modificación y en una baja. Por lo tanto, mezclando ambas cosas tendremos nueve maneras o formas de lanzarlos

 ¿En qué orden son lanzados los triggers?

1. Trigger anterior

2.La acción asociada: alta, modificación o baja

3. Trigger interno

4. Actualizaciones, que veremos a continuación

5. Trigger posterior.

A la hora de usar los triggers debemos de tener en cuenta varias particularidades: en la versión C/S no incluir  nada que implique la intervención del usuario, por ejemplo, visualizar un mensaje, mostrar un formulario, una pregunta, petición de un dato, etc. El motivo es que este tipo de operaciones se llevan a cabo en el Servidor, por lo que el mensaje o el formulario no serían presentados en el Cliente, sino en el propio Servidor. Si en un evento de tabla se incluyese algo que implicase la intervención del usuario, será obviado por el Servidor. Sólo en los triggers anteriores a se pueden cambiar valores de campos de las fichas , si ponemos una instrucción de proceso “modificar campo” ésta sólo se ejecutará si el trigger es anterior a.

Campos de tipo fórmula.

Los fórmula se diferencian esencialemente de los de tipo Alfa y numéricos en que la persistencia en disco es la fórmula en sí, no el resultado de la misma. Esto quiere decir que lo que se guarda es la fórmula que calcula el valor del campo , no el valor en sí. Esto implica que cuando queramos acceder al valor calculado la fórmula se recalcula. Esto lo tenemos que tener en cuenta a la hora de la presentar datos en pantalla a través de una rejilla en arquitectura C/S. Muchos registros como campo fórmula relentizará la presentación pues elevará el número de sockets que viajan por la red para poder mostrar los valores, sobre todo con el de tipo fórmula histórico.

Otra característica común es que no se pueden indexar, no podemos alimentar un índice con este tipo de campos, lógico por otra parte dado que se guarda la fórmula para calcular, no el valor calculado.

El uso de un tipo u otro depende del tip de  resultado final a obtener no de los parámetros que se usen para calcularlos, es decir, si lo que buscamos es un resultado tipo alfabético, usaremos un campo fórmula alfabética, aunque para su cálculo interevengan campos o variables de tipo numérico o de fecha. Las expresiones fórmula las construiremos con el asistente para la creación de fórmulas ya conocido

Los tipos son los siguientes:

- Fórmula numérica: buscamos un resultado de tipo numérico.

-Fórmula alfabética: buscamos un resultado alfabético, concatenando campos, variables o constantes. Es combeniente que la expresión fórmula comience por dobles comillas “”+fórmula.

-Fórmula fecha: bucamos un resultado tipo fecha.

-Fórmula tiempo: retorna un resultado tiempo. No suele ser muy utilizada al igual que el campo tipo tiempo.

-Fórmula histórico: con esta fórmula nos recorremos el histórico seleccionado completamente y se efectúa el cálculo de la fórmula por cada registro  del histórico. Mucho cuidado con este tipo de campos. Particularmente, no me gusta mucho usarlos pues relentizan muchísimo las ejecuciones cuando tenemos muchos datos de histórico. Yo prefiero hacer actualizaciones ( las veremos más adelante )  a un campo de la Maestra en el que llevar el cálculo de la suma de los históricos.

-Fórmula dinámica. A pesar de tratarse de un campo fórmula, tiene persistencia en disco. Este tipo de campo será utilizado cuando la definición de la fórmula deba ser establecida por el usuario en tiempo de ejecución. Aclarar que una cosa es la fórmula en sí y otra el resultado de ejecutarla; en este tipo de campo se guardará la fórmula pero su resultado solamente podrá obtenerse a través de otro campo fórmula (numérica, alfabética o fecha, en función del resultado que deba obtenerse) en cuyas propiedades se establezca como fórmula a ejecutar el campo tipo fórmula dinámica. El rango máximo del campo es 512 bytes.Si en un formulario se incluye un control de edición para editar este tipo de campo, en tiempo de ejecución se incrustará en el mismo un botón que dispara el asistente para la edición de fórmulas, para facilitar al usuario su composición.

A veces una información visual del tipo de campo que se está usando es muy eficiente.

A la izquierda teneis los logos que Velneo usa para indicarnos el tipo de campo que tenemos.

Enlazar tablas de datos en Velneo es fácil con el uso del enlazador en el esquema de tablas. Cuando conectamos dos tablas entre sí, se crean dos relaciones distintas, una desde la tabla que actúa como maestra hacia la que actúa como histórica y que llamaremos enlace histórico ( EH a partir de ahora) y otra desde la que actúa como histórica hacia la que actúa como maestra y que llamaremos puntero a maestro (PAM a partir de ahora ). El EH nos permite relacionar una ficha de la tabla maestra con varias fichas de la tabla histórica ( relación singular->plural ) con lo que desde una ficha de maestro podemos ver muchos históricos. En cambio el PAM relaciona cada ficha de la tabla histórica con una sola ficha de la tabla maestra ( relación singular->singular ).

En C y en C++ ,un puntero es un tipo especial de variable, que almacena el valor de una direccion de memoria. En Velne

o un puntero es un campo de una tabla en el que se guarda la posición de un registro en otra tabla. Si pudiéramos hacer un simil con la física, un puntero es como un vector. Su punto de origen es un registro de la tabla histórica, su sentido va desde la histórica a la maestra y su punto destino es e registro de la tabla maestra apuntada.

¿Para qué sirve el PMA? Sirve sobre todo para saber siempre a qué registro de la maestra estoy aputando, en un ejemplo concreto el puntero a maestro CLIENTES desde una tabla CABECERA DE FACTURAS, me indicará a qué ficha de CLIENTES  pertenece dicha FACTURA. El dato que guarda el campo puntero es el CODIGO de la ficha del cliente al que pertenece la factura.

La utilización de los PAM también nos dá economía de espacio en disco. El hecho de tener guardado sólo el código de la ficha maestra nos evita introducir los datos del cliete cada vez que le hagamos una factura. Simplemente indicándole a qué cliente pertenece mediante el puntero, tenemos la relación establecida.

El EH nos permite conectar una única ficha con muchas fichas de su histórico. Todo EH se establece mediante un índice de la tabla histórica pero no se guarda en un campo como el PMA sino en un componente especial de las tablas llamado Históricos. Los enlaces a histórico pueden ser múltiples, dependiendo de qué indice usemos en la tabla histórica para acceder a sus datos desde la maestra.

Cuando realizamos un enlace entre dos tablas mediante el esquema de tablas y el enlazador se producen varios cambios en las mismas, sobre todo en la tabla que actúa como histórica. Seguiremos con el ejemplo de CORDILLERAS (maestra ) y MONTAÑAS (histórica ).

Si nos fijamos en la tabla Montañas , veremos que se han producido dos cambios: en los campos ha aparecido uno nuevo CORDILLERAS.Este es el puntero a la tabla maestra

Si entramos en sus propiedades veremos ahora que está Enlazado a Tabla de Datos Maestra y el nombre a la tabla que apunta, CORDILLERAS.

Además se ha creado un índice nuevo llamado también Cordilleras, del tipo Aceptar repetidas, es decir, puede haber más de un registro de esta tabla (MONTAÑAS ) cuyo puntero sea el mismo a CORDILLERAS:  puede  haber muchas MONTAÑAS que pertenezcan a la misma CORDILLERA. Vemos también que ese índice está “alimentado” por el campo puntero Cordilleras.

En la tabla maestra, ha aparecido un nuevo componente histórico, el historico a montañas. Si abrimos las propiedades de dicho EH, veremos que apunta a la tabla MONTAÑAS a través del índice CORDILLERAS  de dicha tabla. Esto permitirá que desde una ficha de CORDILLERAS veamos un histórico de sus MONTAÑAS ordenado por el índice, es decir, nos ordenará el listado de MONTAÑAS  de dicha CORDILLERA  según el orden en que los hayamo introducido.

Imaginemos que queremos que nos ordene ese histórico por la altura de dichas montañas. Creamos en la tabla un campo altura numérico de longitud 3 y con dos decimales sin signo. Creamos un índice nuevo al que podemos llamar Alturas que estará formado por los campos Cordilleras y Alturas, “alimentamos” el índice con los valore de los dos campos. En la tabla CORDILLERAS, nos posicionamos sobre la carpeta Históricos y damos a la tecla Insert o bien, tabla->nuevo objeto de tabla->enlace histórico.

Tabla de datos enlazada: MONTAÑAS  Indice: Alturas. Al cargar ahora con este nuevo EH la tabla de MONTAÑAS desde una ficha de COORDILLERAS nos mostrará las montañas que pertenecen a esa cordillera ordenadas por su altura ( siempre de valores más bajos a valores más altos ).

Podremos de esta forma crear los EH que necesitemos para poder ver los históricos de una ficha maestra ordenados de la forma que necesitemos, pudiendo jugar con la composición de los índices que usamos para enlazar contra la histórica.

 Espero que los enlaces empiecen a ser más claros y que veais la potencia que nos brindan  a la hora de organizar la información de nuestras aplicaciones de una manera lógica y sencilla.

Ya tenemos nuestra primera tabla creada, sólo con los campos e índices que vienen por defecto al crear una Maestra.

 En el vDeveloper tendríamos la tabla con cada uno de sus componentes, en nuestro caso los dos campos y los cuatro indices que se han creado por defecto.

Si nos fijamos, a la derecha de la Descripción de la tabla, a parece la letra D. Esto significa que la tabla tiene permanencia en el Disco.

Si nos posicionamos sobre la tabla y usamos la combinación de teclas Alt+ Intro llegaremos a un cuadro de diálogo en el que tendremos más información sobre la tabla

En este cuadro de propiedades de la tabla, podremos cambiar tanto el plurarl como el singular, el tipo de tabla, en qué lugar reside la tabla, es decir si está en Disco Compartida y en ese caso en qué directorio, el de la aplicación o un directorio aparte en el que compartan tablas de datos distintas aplicaciones, en Memoria, el número de Bytes que ocupa cada ficha así como el número de campos e índices que tiene. Estos tres datos numéricos son calculados por Velneo y no es posible cambiar su valor

El check de Privada afectará más adelante al acceso o no desde el Editor de Personalizaciones de Velneo. Si estuviera marcada como Privada, no es posible el acceso para personalizar ciertos objetos visuales.

Se puede añadir un comentario que no se verá en ejecución y que sólo será visible con el vDeveloper. Puede ser interesante usar este comentario sobre todo a la hora de documentar, cuando la aplicación ya tiene muchas tablas.

Poscionémonos sobre el campo Nombre y hagámos doble click con el botón izquierdo del ratón.

Entraremos en el cuadro de propiedades generales de un campo.

Nombre: es el nombre o descripción que tendrá el campo. Será el que aparezca cuando incluyamos el campo en un objeto visual. Para el nombre del campo no podremos usar los caracteres reservados % ni $

Enlace: en un artículo posterior trataremos los distintos tipos de enlaces que existen en Velneo. Por ahora, nos quedaremos con que los campos que no dependen de otras tablas NO están enlazados.

Tipo: En el podremos escoger entre distintos tipos de campo Alfabético, Alfa128, numérico, formula, objeto… los veremos con más detenimiento más adelante.

Formato: dependiendo del tipo de campo tendremos que decir su longitud ( común ) el número de decimales (sólo numéricos) signo ( sólo numéricos), su rango o valores mínimo y máximo que le permitimos tener.

Contenido inicial: es una expresión fórmula que será el contenido inicial del campo.

Con el asistente para la edición de fórmulas nos vamos a encontrar muchas veces en el vDeveloper. Es una herramienta muy potente para crear fórmulas de todo tipo, pues podemos acceder a una serie de elementos ya incluidos en el vDeveloper y que nos facilitarán la labor en muchos aspectos del diseño de nuestro proyecto. Podremos  acceder a funciones ya programadas, a campos, a variables globales, locales y de sistema. En una entrada futura veremos esta magnífica herramienta con más detenimiento.

Tipos de campos

Velneo nos ofrece la posibilidad de usar varios tipos de campos, entre ellos los de tipo alfa, los numéricos, fechas, horas, tiempo, objetos y fórmulas.

Alfabéticos :tipo alfabético estándar que incluye todos los caracteres de la tabla ANSI. Se recomienda usar los tipos Alfa  para ahorrar espacio en disco. El rango máximo del campo es 512 bytes. De hecho, dado que Alfa128 cubre casi todos los caracteres escepto los especiales como \ ó @ , es recomendable el uso de campos alfabéticos sólo en el caso de necesitar este tipo de caracteres, p. ej en un campo en el que tengamos que guardar una dirección de correo electrónico o una URL.

Alfa 128: es un tipo alfanumérico,incluye letras mayúsculas, minúsculas, acentos, signos de puntuación y números. Este tipo de campo es empaquetado y cada 8 caracteres que el usuario introduzca se comprimen en 7 para grabarlos al disco. El rango máximo del campo es 512 bytes.

Alfa 64: es un tipo alfanumérico, incluye letras mayúsculas, signos de puntuación y números. Este tipo de campo es empaquetado y cada 4 caracteres que el usuario introduzca se comprimen en 3 que serán grabados al disco. El rango máximo del campo es 512 bytes.

Alfa 40: Es un tipo alfanumérico: incluye letras mayúsculas, números, guión y espacio. Este tipo de campo es empaquetado y cada 3 caracteres que el usuario introduzca se comprimen en 2 que serán grabados al disco. El rango máximo del campo es 512 bytes.

Numérico: Usado para datos numéricos. El rango máximo es de 6 bytes y puede tener decimales y signo.

Fecha: Permite introducir fechas con diversos formatos. Los formatos permitidos son: ddmmaa,dd-mm-aaaa, dd-mmm-aaaa. El carácter de separación puede ser el guión o la barra.

Hora: Permite introducir horas en formato HH:MM:SS.

Tiempo: Permite introducir tiempos con el formato DD:MM:AA HH:MM:SS. Es aconsejable tratar las fechas y las horas por separador, es decir, crear un campo de tipo Hora y un campo de tipo Fecha en lugar de uno de este tipo.

Booleano: Es un campo lógico que permite fijar el contenido del mismo como SÍ / NO (1 ó 0). Veremos cómo a la hora de crear índices, la existencia de un booleano en la tabla nos va a permitir condicionar según el valor de ese booleano ( 0 ó 1 ) la indexación o no de una ficha.

Texto: Su contenido es texto de longitud variable, ocupando solamente el tamaño del contenido. Normalmente es usado para anotaciones en la ficha de un cliente, artículo, etc. En formularios de edición de ficha existe un control específico para editar este tipo de campo. En dicho control de edición sólo hay que tener en cuenta que en ejecución, un salto de linea se introduce con la combinación de teclas Ctrl+Intro, combiene recordárselo al usuario con un pequeño texto estático encima del control de edición.

Objeto Dibujo: Su contenido es un gráfico con cualquier resolución y número de colores que será importado en tiempo de ejecución. Normalmente son usados para ver la imagen del artículo en su ficha, la foto del logotipo del cliente, etc. En formularios de edición de ficha existe un control específico para editar este tipo de campo.

Objeto Texto enriquecido: Su contenido es un documento de texto RTF. Se diferencia del Objeto Texto en que admite cambiar fuentes, estilos, alineación, etc. en tiempo de ejecución. En formularios de edición de ficha existe un control específico para editar este tipo de campo.

Objeto OLE genérico: Su contenido será cualquier objeto OLE. Para cargarlo en tiempo de ejecución se utilizará el cuadro de diálogo Insertar Objeto estándar de Windows. Una vez incorporado el objeto OLE a Velneo podrá ser lanzado directamente en el programa correspondiente haciendo doble clic sobre él. En formularios de edición de ficha existe un control específico para editar este tipo de campo.

Objeto E-mail: Su contenido será un mensaje de correo electrónico (un e-mail). En formularios de edición de ficha existe un control específico para visualizar el contenido de un campo de este tipo.

Objeto Binario: Su contenido será cualquier tipo de archivo; éste será guardado en el contenedor en formato binario. Existen funciones de proceso específicas tanto para importar como para exportar archivos en este tipo de campos. La única forma de trabajar con este tipo de campo es vía proceso, pues no existe un control específico para su edición.

Cuando en una tabla del proyecto se introducen campos de tipo Objeto, al ejecutar la aplicación se crearán además del .dat y del .idx dos nuevos ficheros llamados tabla.cnd que es el contenedor de objetos de la tabla y el tabla.cni que es el índice del contenedor. Este tipo de campos no se guardan por tanto en el .dat como el resto de los campos y tampoco pueden ser utilizados como componentes de índices.

Veremos en el siguiente artículo los campos de tipo fórmula.

Una vez que hemos visto cómo usando las frases podemos establecer qué tablas actúan como maestras y cuáles como históricas, vamos a plasmarlo en del vDeveloper. Para ello usaremos el esquema de tablas          al que accederemos con el icono de la derecha del todo de la imagen.

El esquema de tablas, aparecido en la versión 2.1 , es un importante asistente a la hora de establecer enlaces entre las tablas de nuestras aplicaciones.

Podemos tener en nuestra aplicación tantos esquemas de tablas como necesitemos, pintando en ellos las tablas que  necesitemos. Por ejemplo, podemos tener un esquema para reflejar las relaciones de las tablas de Ventes, otra para las Compras, otra para la Facturación… En el esquema podemos apreciar un area grande a la derecha, en donde se irán pintando las tablas y en la izquierda y de arriba abajo, tres partes, la superior en la que nos vienen listados todos los esquemas que tenemos ( para cambiar de nombre a un esquema sólo hay que posicionarse sobre él y pulsar la tecla F2 ), las tablas del esquema que nos lista las tablas que tenemos en ese esquema en concreto, y las tablas no usadas que son las que no hemos incluido en el esquema en que estamos. Para “sacar” al esquema una tabla que no está, basta ponerse sobre ella en Tablas no usadas y hacer doble click con el botón izquierdo del ratón. Para eliminarla del esquema, que no de la aplicación basta posicionarse sobre ella y pulsar Supr.( eliminar una tabla de un esquema no hace que esta se borre de la aplicación )

Podemos desde aquí crear las tablas, o bien acudiendo al almacén de objetos o a la barra que aparece en la parte  izquierda del editor de esquemas. En ella podemos encontrar, de arriba abajo      

• Botón para ocultar la parte izquierda                                                                    
• Botón para nueva tabla Maestra
• Botón para nueva tabla Submaestra
• Botón para nueva tabla Maestra de Clave Arbolada          
• Botón para nueva tabla Histórica.

Usaremos el de la tabla maestra para crear una tabla de Cordilleras y otra de Montañas. Tal y como habíamos analizado en el anterior artículo, Cordilleras es maestra de Montañas. Recomiendo que a la hora de utilizar los esquemas, coloqueis las maestras en la parte de arriba del esquema, y sus histórcas por debajo, esto os dará una ventaja a posteriori pues con un simple vistazo del esquema sabreis qué tablas actúan como maestras y cuáles como históricas.

 Una vez colocadas en el esquema, nos queda establecer la relación entre ambas. Para ello usaremos el enlazador.Vamos a establecer la relación Cordilleras es maestra de Montañas, de singular Cordilleras a plural Montañas. Si posiciono el ratón sobre el cuadrante gris superior izquierda de la tabla Cordilleras, aparecerá el icono de una mano además del tooltip que se ve en la imagen. Una vez que aparezca la mano pulsamos botón izq del ratón y aparece una flecha roja. Esta flecha roja nos indica que vamos a establecer una relación de Maestro-Histórico con otra tabla. Arrastraremos sin soltar( con la flecha roja visible ) hasta la tabla Montañas y una vez sobre ella dejaremos de pulsar el botón.

Con ello ya habremos logrado enlazar las dos tablas. El puntero azul, indica que la relación entre Montañas y Cordilleras es de uno a uno ( Una Montaña está en una y sólo en una Cordillera ) mientras que el puntero rojo indica una relación de uno a muchos ( una Cordillera puede tener muchas Montañas )

Esta forma de “pintar” las relaciones entre tablas que Velneo nos proporciona, resulta una herramienta muy potente a la hora del análisis e implementación de nuestras bases de datos. Es básico y fundamental aprender a analizar bien y sacarle así todo el rendimiento al vDeveloper.

 Siguiendo el mismo procedimiento de creación de enlaces, podemos enlazar también las tablas del ejemplo de los Artículos y los Almacenes con la histórica de ambas ( recordemos que las frases válidas y más lógicas eran  LOS ALMACENES DE LOS ARTÍCULOS y LOS ARTICULOS DE LOS ALMACENES  plural-plural ) que nos permitirán navegar desde la tabla de Almacenes hasta la de artículos y viceversa.

Hemos de tener en cuenta que , si existen distintos punteros por los que navegara para moverse por las disitintas tablas, esto indica que desde una tabla se puede acceder a los datos de la otra. Es decir, desde Almacenes, puedo navegar al histórico de Existencias, para ver los Artículos que contine, y al revés, desde Artículos puedo navegar al histórico de Existencias para luego navegar por el maestro Almacenes

El modelo real de Velneo me encanta. No he encotrado una forma más sencilla, intuitiva y directa para diseñar las relaciones entre las tablas que las  que Velneo establece. Su modelo no obliga a que la información se adapte a la informática sino que la informática se adapta a la información, de una manera que yo suelo llamar natural.

Cuando asistí al primer curso , Juan nos enseñó una forma de analizar que me parece fácil e infalible, se trata del método de las frases. Escojamos dos tablas cualesquiera e intentemos crer las frases de singular y plural y ambos plurales. Veamos.

Cordilleras y Montañas. Construyamos las frases

1. La Cordillera de una Montaña
2. Las Cordilleras de una Montaña
3. Las Cordilleras de unas Montañas
4. La Montaña de una Cordillera 
5. Las Montañas de una Cordillera.

¿De las cincon frases cuál de ellas tiene más sentido? La número 5 es la más lógica. Por tanto Cordillera es el singular y Montañas es el plural: el singular es siempre la tabla que actúa como maestra y el plural la que actúa como histórica. La tabla Cordilleras es la maestra de Montañas.

Clientes y Cabeceras de Facturas o Facturas.

1. Los Clientes de una Factura
2. El cliente de una Factura
3. Las Facturas de un Cliente
4. La Factura de los Clientes
5. Las Facturas de los Clientes

La más lógica es la número 3, un cliente tiene muchas facturas, y una factura sólo se le puede imputar a un cliente. El singular es Cliente y el plural Facturas, luego Clientes es maestra de Facturas.

Veamos un caso en el que la frase correcta es la plural-plural.

Tenemos Artículos y Almacenes en una aplicación  multialmacén.

1. El Articulo de los almacenes
2. Los Artículos de los almacenes
3. El Artículo de un almacén.
4. Los almacenes de un artículo
5. Los almacenes  de los artículos

Todas las frases tienen sentido, por tanto no podemos decir que una tabla es maestra de la otra. Para poder solucionar esta situación necesitaremos una tabla intermedia que nos permita relacionarlas. Creemos por ejemplo una tabla llamada Existencias. Haremos que tanto Artículos como Almacenes sean maestras de Existencias, con lo que tendremos conectados a través de ella los datos de las dos tablas, así  de un Artículo veré las Existencias en los distintos Almacenes, y en un Almacén las Existencias de los distintos Artículos.

Siguiendo este método de las frases, aunque la aplicación vaya teniendo cada vez más tablas, no tendremos fallos en el análisis y por tanto en la estructuración de las tablas que es la piedra angular sobre la que se deben basar nuestras aplicaciones.

La espina dorsal sobre la que descansa Velneo son sus tablas y la forma que tienen de relacionarse entre sí. El tipo de tabla más usado y sobre el cual descansan todas las demás es la Maestra Normal de Clave Numérica. De hecho es completamente posible construir una aplicación entera sólo usando este tipo de tabla. Escojamos en la Galería de Objetos una tabla Maestra para seguirla como ejemplo y ver sobre ella las características principales. En el siguiente cuadro de diálogo podemos empezar a observar las características de una Maestra. Es una tabla que tiene un campo de tipo numérico llamado Código que identifica de manera inequívoca a cada uno de sus registros, logrando esto con una indexación de dicho campo, creándose un índice llamado asi mismo código que se ” alimenta” con los valores de dicho campo y haciendo que dicho índice sea de clave única , es decir, impidiendo que  haya dos o más registros de la tabla en el que dicho campo tenga el mismo valor. Esta exclusividad de valor del Código de cada registro de la tabla es importantísimo y construye la integridad de los datos de la tabla.Veamos detenidamente el cuadro de diálogo de esta tabla. En la parte superior del mismo y bajo la leyenda NOMBRE nos aparecen dos cuadros de edición para rellenar, el Plural y el Singular. El Plural sería el nombre en plural que le queremos dar a la tabla, por ejemplo Personas, y el singular el nombre para referirnos a un único registro. Aunque parezca no tener importancia, estas dos características de las tablas las usaremos más adelante en los nombres que dará a los distintos objetos visuales asociados a dicha tabla, dándoles como nombre inicial por defecto a los formularios el nombre Singular ( pues sirven para representar un único registro ) y a las rejillas el nombre plural pues sirven para representar más de un registro de una tabla.DATOS DE LA CLAVE: nombre del campo Código. Velneo mismo recomienda no cambiar el nombre ni del campo ni del índice.Por defecto viene marcado el flag Numeración automática con lo que según vayamos dando de alta fichas en la tabla, el campo código se irá rellenando automáticamente con valor del último registro grabado+1. Algo más adelante veremos cómo podemos cambiar esto y optar por dos alternativas más, contador en variable o ninguno. La longitud variará desde 1 byte hasta 4 bytes, lo que nos dá una capacidad máxima de 4.000.000.000 (cuatro mil millones ) de registros en una única tabla. La forma más habitual es la de Siguiente al último o Numeración automática. Pasemos ahora a los DATOS DE DESCRIPCION. Velneo, al crear una tabla Maestra,  genera automáticamente dos campos, el Código que ya hemos visto y el campo Nombre. Se usa como campo de descripción del registro, principalmente, y por defecto lo crea de tipo Alfa 128 con 35 caracteres de longitud. También en este campo, Velneo nos hace una serie de recomendaciones a tener en cuenta aunque no son tan restrictivas como las del Código. Observemos que aparecen marcados por defecto los flags Indice alfabético, Indice por palabras, Indice por trozos de palabra. Los índices es la segunda piedra angular de las tablas. Si los campos defienen los componentes de cada registro de la tabla, los índices nos ayudan a encontrar a encontrar los datos que buscamos por un determinado criterio. Todos conocemos los índices de capítulos de un libro, pero puede haber también un índice honomástico para encontrar los nombres de los personajes, un índice cronológico de fechas… ordenación de los datos por un criterio u otro, en definitiva.

Velneo, cada vez que se graba un registro en una tabla, indexa dicho registro por todos los criterios o índices que tenga la tabla, para poder luego encontrarlos y acceder a ellos más rápidamente.

• Indice alfabético: ordenará o indexará los registro de forma  alfabético.
• Indice por palabras: inedexará los registros por todas y cada una de las palabras de las que conste el campo. Si usamos el campo para introducir un nombre de un cliente, p.ej Angel Dominguez Esteba, usando el índice por palabras nos encontrará dicho registro tanto por la palabra Angel, como por Dominguez como por Esteba.
• Indice por trozos de palabra: también conocido com aproximación alfabética ternaria.Al usar este índice, el dato es indexado por todos y cada uno de los trozos de al menos tres caracteres seguidos en los que dicho dato se pueda partir. Por ejemplo, un dato como “velneo” se indexará por vel, veln, velne, velneo, eln, elne, elneo, lne,lneo, neo, pudiendo por tanto buscarse ese dato por cada una de estas combinaciones de caracteres. Como podemos observar, no es necesario que la terna de caracteres sean los iniciales, basta con que estén dentro de la cadena de texto a buscar y en su orden.

Si pulsamos la tecla Aceptar  volvemos de nuevo a la pantalla principal del editor .

Podemos ver tanto el nombre de la tabla como las cuatro carpetas de componentes que tiene la tabla. Aquí vale la pena que observemos que no es lo mismo el identificador de la tabla que el nombre de la tabla. El segundo es la palabra que aparece bajo la columna de Descripción. El primero, el identificador, es lo que aparece bajo la columna de Tablas de datos, justo al lado del icono de la tabla. El identificador le servirá al sistema operativo para formar los archivos que genera cada tabla y nombrarlos antes de la extensión, por lo tanto hemos de tener en cuenta que aunque el identificador de la tabla conste de más de 8 caracteres, el S.O. sólo guardará los 8 primeros para dar nombre a dichos archivos, con lo cual debemos de tener cuidado a la hora de nombrar las tablas para que no haya varias en las que sus 8 primeros caracteres coincidan . Cuando ejecutemos por primera vez nuestra aplicación, Velneo genera entre otros más , al menos dos fichero por tabla: el fichero  tabla.dat  en donde se guardan los datos de los registros ( valores de campos ) y el ficheo tabla.idx donde se guardan los índices.

Podemos cambiar el identificador de la tabla haciendo que esta gane el foco y pulsando la tecla F2, e igualmente con ella en el foco y utilizando la combinación de teclas Alt+Intro, podemos cambiar el nombre singular y plural de la tabla.

 El vDevelop es la herramienta por escelencia con la cual vamos a atacar nuestros desarrollos. No es el único componente de Velneo, también tenemos el vRunner o ejecutor monopuesto, el vServer o servidor de aplicaciones y http o el vClient que ataca dichas aplicaciones.

Pero lo que afecta más al desarrollador es el vDevelop, el antiguo Editor.Cuando lo abrimos observamos que la pantalla

 queda dividida en dos zonas principales, la parte derecha, en la que iremos insertanto los objetos visuales que necesite nuestra aplicación, ( formularios, rejillas, procesos…) y la parte izquierda, a su vez divida en superior e inferior.

En la parte inferior tendremos las variables globales de nuestro proyecto, las cuales podremos organizar en carpetas. Y en la parte superior derecha, el alma mater de Velneo, el sitio en donde se define una aplicación en su 90%, las tablas.

Además tedremos en este mismo apartado los directorios de tablas, las tablas estáticas, las plantillas de campos, las bases de datos externas y las librerias de funciones dll.

Pero la parte fundamental está en las tablas. En ella se establecen los cimientos  sobre los  que descansa toda la potencia que nos dá Velneo como base de datos real .

En la barra de herramientas de Velneo, contamos con el almacén de objetos o como yo lo llamo “Cubo de Rubik” en el cual tenemos todos los elementos de los que podemos disponer con el el vDevelop. La primera opción de todas, el primer elemento de la columna de la izquierda son las Tablas de Datos.

Los seis tipos de tablas que se nos presentan, pueden resumirse en tres principales a mi entender: Maestras, Submaestras e Históricas. Las Maestras con clave arbolada puede considerarse una maestra “especializada” en la que el campo y el índice código , en vez de ser numérico , es de tipo Alfa.

Las maestras de segundo nivel con clave numérica no son tablas en realidad sino una forma de definir relaciones entre varias tablas, estableciendo las maestras de una dada, una forma de enlazar en vez de usar los esquemas. Por último la Histórica doble, es una forma que yo considero arcaica de intentar lo que las submaestras viniron a suplir, estructuras de tablas Cabeceras-Lineas en su forma más primitiva. Particularmente yo no las utilizo ahora pero en mis comienzos si las utilizaba.

Sea cual sea el tipo de tabla que elijamos, veremos que los componentes de una tabla son cuatro: los campos, los índices, los históricos, las actualizaciones y los triggers o procesos o manejadores de eventos.

Iremos viendo en sucesivos artículos todas y cada una de las tablas así como sus componentes.