Triggers o eventos de tabla: Qué son y cómo funcionan

¿Sabes que con los triggers o eventos de tabla puedes realizar acciones antes, durante o después de dar de alta, modificar o eliminar un registro?

Primero vamos a definir que son los triggers o eventos de tabla.

Según la definición de Velneo

Un trigger es un proceso definido por el programador que es ejecutado automáticamente al producirse el evento al que hace referencia.

Desde este enlace puedes acceder a la ayuda oficial sobre los triggers.

Consideraciones importantes sobre los triggers

Antes de ver los tipos de triggers que Velneo pone a nuestra disposición, déjame que te cuente 2 consideraciones muy importantes por si hay algún despistado en la sala… “que haberlos haylos”.

  • Son “eventos de tabla”… por lo tanto se ejecutan en el servidor. No pongas ninguna instrucción que requiera la interacción con el usuario, puesto que no lo verá.
  • Cualquier cambio que se desee realizar en la ficha en la que nos encontremos, siempre deberá ser hecho antes de su grabación, es decir, en el trigger anterior.

Avisado quedas… ¿Vale Rodolfo?

Tipos de triggers o eventos de tabla

Un trigger es un subobjeto del objeto tabla por lo tanto para crearlo tendremos que hacerlo desde el panel de subobjetos de la tabla en cuestión o bien desde la barra de opciones de menú de dicha tabla.

Al dar de alta un nuevo trigger, nos aparece el siguiente formulario:

Tipos de Triggers

Como podéis ver, tenemos 9 triggers disponibles:

  • 3 correspondientes al alta de una ficha.
  • 3 correspondientes a la modificación de una ficha
  • 3 correspondientes a la baja de una ficha.

El tipo de trigger a utilizar dependerá de 2 factores:

  • Si queremos modificar en el proceso la ficha en la que estamos posicionados
  • Si queremos realizar las acciones antes o después de que se lancen las actualizaciones programadas en la tabla.

Además, sobra decirlo, la primera instrucción del proceso tendrá origen ficha.

  • Alta: Anterior a un alta de ficha: el proceso se lanza cuando la ficha todavía no ha sido dada de alta en la base de datos, por lo que podemos realizar cambios en sus campos.
  • Alta: Interno a un alta de ficha: el proceso se lanza cuando la ficha ya ha sido dada de alta en la base de datos, por lo que no podemos realizar cambios en sus campos, pero todavía no se han lanzado las actualizaciones.
  • Alta: Posterior a un alta de ficha: el proceso se lanza cuando la ficha ya ha sido dada de alta en la base de datos, y además ya se han lanzado las actualizaciones.
  • Modificación: Anterior a una modificación de ficha: el proceso se lanza cuando la ficha todavía no ha sido modificada en la base de datos, por lo que podemos realizar cambios en sus campos.
  • Modificación: Interno a una modificación de ficha: el proceso se lanza cuando la ficha ya ha sido modificada en la base de datos, por lo que no podemos realizar cambios en sus campos, pero todavía no se han lanzado las actualizaciones.
  • Modificación: Posterior a una modificación de ficha:  el proceso se lanza cuando la ficha ya ha sido modificada en la base de datos, y además ya se han lanzado las actualizaciones.
  • Baja: Anterior a una baja de ficha: el proceso se lanza cuando la ficha todavía no ha sido eliminada de la base de datos.
  • Baja: Interno a una baja de ficha: el proceso se lanza cuando la ficha ya ha sido eliminada de la base de datos, pero todavía no se han lanzado las actualizaciones.
  • Baja: Posterior a una baja de ficha: el proceso se lanza cuando la ficha ya ha sido eliminada de la base de datos y además ya se han lanzado las actualizaciones.

Por si no ha quedado todavía lo suficientemente claro, te dejo un esquema que lo aclara mas.

Esquema sobre triggers

 

¿Alguna duda sobre los triggers o eventos de tabla?

Cuéntamela dejándome un comentario mas abajo.

La entrada Triggers o eventos de tabla: Qué son y cómo funcionan aparece primero en AyudaVelneo.

La Tabla estática en un Combo sin Origen

La Tabla estática es un objeto del proyecto de datos cuyos registros se pueden crear y editar en tiempo de diseño. En tiempo de ejecución solo podemos mostrar los registros de la Tabla estática sin posibilidad de filtrarlos (siempre se muestran todos) o modificarlos.

Seguramente alguna vez has tenido la necesidad de mostrar los Items de una Tabla estática en un formulario sin Origen o filtrar los registros de la Tabla estática de forma dinámica. En estos casos el API de Velneo viene en nuestra ayuda, veamos cómo hacerlo.

tabla estática

 

Para definir la tabla estática tenemos que crear registros o Items con 3 propiedades:

    • Identificador de un solo caracter alfanumérico que identifica de forma unívoca el registro
    • Nombre para mostrar en el Interface de usuario
    • Dibujo que se corresponde con un Objeto dibujo del proyecto para mostrar también en el interface de usuario

El uso más común de la Tabla estática consiste en enlazar un campo a dicha tabla mediante un enlace de Tipo estática. Lo que se guarda en el campo enlazada es el Identificador del Item seleccionado.

En tiempo de ejecución el usuario podrá desplegar un control Combobox en el formulario con todos los elementos de la Tabla estática y cambiar el Identificador guardado en el campo indicado en la propiedad Contenido.

Como vemos en la siguiente imagen tenemos un formulario de configuración con un Combobox CBO_LOGNIVEL mostrando los 5 Nombres de una Tabla estática con el Dibujo a la izquierda. 

Los Identificadores son los caracteres 1, 2 ,3 4 y 5.

Este formulario no tiene Origen de tabla y por lo tanto no podemos fijar la propiedad “Contenido” del Combobox a un campo de dicha tabla.

El valor del Identificador seleccionado en el Combobox se guardará en una variable global numérica G_APP_LOG_LEVEL.

En el POS_INI del formulario ejecutamos el manejador javascript LOGNIVEL_RELLENAR_JS que nos permite acceder a los Items de la Tabla estática y rellenar con ellos el Combobox. Como la propiedad Contenido del Combobox ya nos es operativa debemos gestionar la selección y lectura del Item, algo que ocurre de forma automática cuando el contenido es un campo.

// Formulario sin Origen
// Manejador de Evento JS - LOGNIVEL_RELLENAR_JS
// Rellena el Combobox con los Items de la tabla estática

var cAliasAPP = theApp.mainProjectInfo().alias()
var cAliasDAT = cAliasAPP.replace("app","dat")
var oCbo = theRoot.dataView().control("CBO_LOGNIVEL")
// Obtenemos el número de Items de la Tabla estática
var nNumNiv = theApp.staticTableItemCount(cAliasDAT + "/APP_LOG_LEVEL")

// Rellenamos el Combo desde la Tabla estática con Dibujo, Nombre e Identificador
if (nNumNiv > 0) {
        for (var i=0 ; i<nNumNiv ; i++) {
                oCbo.addItem(
                        theApp.staticTableItemImage(cAliasDAT + "/APP_LOG_LEVEL",i),
                        theApp.staticTableItemName(cAliasDAT + "/APP_LOG_LEVEL",i), 
                        parseInt(theApp.staticTableItemId(cAliasDAT + "/APP_LOG_LEVEL",i)))
        }
}

// Establecemos el Item seleccionado inicialmente desde la variable Global
var nNivel = theApp.globalVarToInt(cAliasDAT + "/G_APP_LOG_LEVEL")
var nIndex = oCbo.findData(nNivel)
if (nIndex > -1) {
        oCbo.setCurrentIndex(nIndex)
}

Cuando el usuario seleccione un nuevo Item del Combo tenemos que guardar el Identificador seleccionado en la variable global G_APP_LOG_LEVEL.

Desde el evento Item: Cambio de seleccionado del Combobox ejecutamos el manejador javascript LOGNIVEL_CAMBIO_JS

// Formulario sin Origen
// Manejador de Evento JS - LOGNIVEL_CAMBIO_JS

var cAliasAPP = theApp.mainProjectInfo().alias()
var cAliasDAT = cAliasAPP.replace("app","dat")
var oCbo = theRoot.dataView().control("CBO_LOGNIVEL")

// Obtenemos el Identificador del Item seleccionado y lo guardamos en la variable global
var nNivel = oCbo.itemData(oCbo.currentIndex)
theApp.setGlobalVar(cAliasDAT + "/APP_LOG_LEVEL", nNivel)

Y esto es todo, el API ha aportado a la programación del Combobox ese grado dinámico que no tenemos en Velneo nativo. Sin embargo perdemos la potencia de la refactorización por lo que tendremos que ser muy cuidadosos con el código.

Hagamos un componente de todo esto

Quizás quieras darle un poco de abstracción a la resolución de este ejercicio y te planteas el diseño de un Combobox personalizable. Un control Combobox que sirva para cualquier Tabla estática del proyecto y tenga los manejadores RELLENAR y CAMBIO incluidos en el componente.

El control Vista de Datos del formulario nos permite incrustar componentes del proyecto e interactuar con él mediante comandos de Velneo.

Veamos como crear un Combobox genérico para mostrar cualquier Tabla estática del proyecto en un formulario sin Origen.

Diseñamos un formulario FRM_SIS_COMBO_ESTATICA sin Origen con un Combobox CBO_ESTATICA y un Label para mostrar la variable local CID_ELEMENTO que guarda el identificador del Item seleccionado.

El formulario FRM_SIS_COMBO_ESTATICA va a ser nuestro componente que insertamos en un formulario sin Origen mediante una Vista de datos.

Este componente necesita 2 valores, el Alias del proyecto de datos CALIAS y el Identificativo de la Tabla estática CTABLA_ESTATICA.

Un manejador de evento javascript CBO_RELLENAR_JS es ejecutado desde el ON_SHOW del formulario. Rellenamos el Combobox en el evento On_Show porque es la única manera de asegurarnos que las variables locales CALIAS y CTABLA_ESTATICA han sido asignadas correctamente a la Vista de datos desde el evento POS_INI del formulario principal.

// Componente Combo de Tabla estática
// Manejador de Evento JS - CBO_RELLENAR_JS
// Rellena el Combobox con los Items de la tabla estática

// El componente necesita personalizar 2 valores: Alias del proyecto y Tabla estática
var cAliasDAT = theRoot.varToString("CALIAS")
var cTablaEstatica = theRoot.varToString("CTABLA_ESTATICA")
var oCbo = theRoot.dataView().control("CBO_ESTATICA")

// Solo rellenamos si el combo está vacío (recordad que estamos en el evento On_Show)
if (oCbo.count == 0) {
        // Rellenamos el Combo desde la Tabla estática
        var nNumNiv = theApp.staticTableItemCount(cAliasDAT + "/ " + cTablaEstatica)
        if (nNumNiv > 0) {
                for (var i=0 ; i<nNumNiv ; i++) {
                        oCbo.addItem(
                                theApp.staticTableItemImage(cAliasDAT + "/ " + cTablaEstatica,i),
                                theApp.staticTableItemName(cAliasDAT + "/ " + cTablaEstatica,i), 
                                theApp.staticTableItemId(cAliasDAT + "/ " + cTablaEstatica,i)
                        )
                }
        }
        // Establecemos el valor inicial
        var cID = theRoot.varToString("CID_ELEMENTO")
        var nIndex = oCbo.findData(cID)
        if (nIndex > -1) {
                oCbo.setCurrentIndex(nIndex)
        }
}

Desde el evento Item: Cambio de seleccionado del Combobox ejecutamos el manejador javascript CBO_CAMBIO_JS

// Componente Combo de Tabla estática
// Manejador de Evento JS - CBO_CAMBIO_JS
// Obtiene el ID seleccionado en el Combobox

var oCbo = theRoot.dataView().control("CBO_ESTATICA")

// Obtenemos el ID seleccionado
theRoot.setVar("CID_ELEMENTO", oCbo.itemData(oCbo.currentIndex))
theRoot.dataView().updateControls()

Con esto ya tenemos el componente terminado y listo para insertarlo como Vista de datos en cualquier formulario sin Origen.

En el manejador POS_INI del formulario principal establecemos la personalización del componente con los valores del Alias del proyecto de datos, nombre de la Tabla estática e Identificador inicialmente seleccionado.

Para recoger el Identificativo seleccionado en el Combobox podemos usar un manejador LOGNIVEL_CAMBIO que se dispare con el evento Item: Cambio de seleccionado del Combobox de la Vista de datos.

Rem (Manejador LOGNIVEL_CAMBIO para obtener el identificativo seleccionado)
Interfaz: Get variable local de vista de datos ( CTR_LOG_NIVEL, CID_ELEMENTO, CID_LOGNIVEL )
Modificar variable global ( APP_LOG_LEVEL@MiProyecto_dat, CID_LOGNIVEL, LOK )

Aquí vemos un ejemplo de la secuencia de eventos en Velneo. Cuando en el Combobox se cambia el elemento seleccionado, primero se dispara el evento Item: Cambio de seleccionado del componente incrustado en la Vista de datos y a continuación se dispara el evento del control Vista de datos definido en el formulario principal.

 

¿Qué pasa con los formularios con Origen si quiero insertar una Vista de datos sin Origen?

Pues también tiene solución, pero eso lo dejo como ejercicio y pones tu solución en los comentarios.

La entrada La Tabla estática en un Combo sin Origen aparece primero en AyudaVelneo.

Consultorio Velneo: ¡Actualizaciones al poder!

Muy interesante la pregunta que me hace David Cueva desde Juarez (México) y que creo que se puede resolver mediante la creación de 3 campos y 1 actualización ¿no te lo crees?.. Sigue leyendo.

Actualizaciones al poder

La pregunta en cuestión es la siguiente:

Tengo un formulario de mantenimiento a x unidad…en el tengo datos de la unidad a servir, fecha, y un boleano que me indicara cuando el mantenimiento actual..esta terminado….abajo….una vista de datos donde esta la rejilla de lineas de mantenimiento (editable)…donde tengo el servicio a dar…y entre otras cosas un campo de finalizado…..
lo que no puedo lograr es que al momento que todas las lineas (servcios), esten en finalizado si….en ese instante me habilite el campo Terninado en el formulario…si hay algun servicio sin terminar…debe permanecer deshabilitado…
Mediante control de evento y eventos….lo hace..pero a destiempo…no en tiempo real…..
Antes de continuar, es muy recomendable que, si no lo has hecho ya, leas este artículo acerca de las actualizaciones.

Definiendo el problema

Básicamente David tiene un registro (maestro) en el que hay que cambiar un campo de tipo booleano en función de si todas sus líneas (plural) están en estado terminado o no (te recomiendo leer también este otro post sobre las relaciones entre tablas).

David lo ha conseguido mediante maneadores de evento pero el problema es que no consigue que el valor del campo booleano se actualice en tiempo real.

Siempre digo que todo lo que podamos hacer en el proyecto de datos, es recomendable hacerlo ahí. Velneo se encargará de realizar las operaciones necesarias para actualizar los registros.

Pues vamos a ello…

Creando los campos necesarios

Para aplicar la solución, en el registro del mantenimiento vamos a crear dos campos de tipo numérico:

  • NUM_LIN_TOT: iremos acumulando en este campo el número de líneas que tiene el registro en cuestión.
  • NUM_LIN_TER: iremos acumulando en este campo el número de líneas que estén terminadas.

Además vamos a modificar el contenido inicial del campo booleano (le llamaremos B_TER) que nos indica si el mantenimiento está terminado o no:

  • choose(#NUM_LIN_TOT= #NUM_LIN_TER, 1, 0)

De esta forma conseguiremos que el campo se marque como “Terminado” cuando el nº de líneas terminadas sea igual al nº de líneas totales.

Velneo se encarga del resto: Actualizaciones al poder

Ahora sólo nos falta que los campos para el número de líneas se vayan actualizando de forma automática.
Para ello vamos a crear una actualización en la tabla de líneas de mantenimiento que actualice el maestro de mantenimientos.
Una vez creada, vamos a dar de alta dos componentes:
Nº de líneas totales
Actualización sencilla… cada vez que demos de alta una línea del mantenimiento… se acumula 1 en el campo NUM_LIN_TOT.

Nº de líneas terminadas

Mediante este componente de actualización, iremos añadiendo 1 al nº de líneas terminadas pero solamente cuando la línea esté terminada (la condicionamos a que el campo B_TER esté a 1).

Conclusión

Pues si esperabas algo mas de dificultad… lo dejaremos para otro día. Con estas sencillas instrucciones, David conseguirá lo que se propone.

Cuando el valor del campo NUM_LIN_TER sea igual al del campo NUM_LIN_TOT, querrá decir que todas las líneas estarán terminadas y por tanto el campo booleano B_TER se marcará a 1.

Ya sabes que si tienes alguna duda sobre Velneo, puedes hacérmela llegar a través del formulario de contacto e intentaré responderla.

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Consultorio Velneo: ¡Actualizaciones al poder! aparece primero en AyudaVelneo.

Consultorio Velneo: Relaciones entre tablas

Nace hoy en el blog la sección “Consultorio Velneo” orientada a resolver las dudas que podáis tener sobre la plataforma Velneo®. El blog sigue aumentando tanto en lectores como en suscriptores y cada vez son más las consultas que me hacéis, sobre todo por e-mail.

He pensado que, quizá, puede ser útil para muchos de vosotros leer mis respuestas, en lugar de enviar el e-mail sólo al desarrollador que tenía la duda.

Además también intentaré responder a cuestiones aparecidas en el foro de Velneo, como es el caso de este post “Relaciones entre tablas“.

El usuario Franpino planteaba en este hilo una cuestión muy interesante y esencial a la hora de desarrollar con Velneo: la relación entre tablas de la aplicación. Si estás comenzando a desarrollar con la plataforma, es muy importante que domines los conceptos de maestro y plural y que sepas diferenciarlos claramente.

Para explicar dicha relación, he seleccionado una serie de tablas de vErp y he creado un esquema a modo de ejemplo:

Relación entre tablas

Antes de comenzar a relacionar las tablas para poder conseguir este esquema, no estaría de mas que refrescases tu conocimiento sobre los distintos tipos de tabla de los que disponemos en Velneo.

Comenzando la relación entre tablas sin tocar Velneo

Lo primero que debemos plantearnos es cómo queremos que se comporte nuestra aplicación en cuanto a los datos se refiere. Voy a comenzar explicando como sería la relación entre las tablas del ejemplo que he planteado sin tocar Velneo:

  • Tabla Contactos: Un contacto puede tener varias direcciones y podemos hacerle varios presupuestos (con lo cual puede tener múltiples líneas de presupuesto en las que le habremos asignado varios artículos). Además sólo tendrá una forma de pago.
  • Tabla Direcciones: Cada dirección SOLO pertenece a un contacto.
  • Tabla Formas de Pago: Ya hemos dicho que un contacto SOLO puede tener una forma de pago, pero la misma forma de pago puede estas asignada a varios clientes. Además en el presupuesto vamos a poder modificar la forma de pago asignada por defecto al contacto. Imaginemos que un contacto siempre paga a 30 días pero un día quiere pagar al contado. Sería absurdo cambiar la forma de pago en la ficha del contacto, hacer el presupuesto y volver a cambiar la forma de pago.
  • Tabla Presupuestos de Venta: Siguiendo con la lógica, un presupuesto estará asignado a un contacto y podrá tener varias líneas de presupuesto. Además un presupuesto sólo tendrá una forma de pago.
  • Tabla Líneas de Presupuesto de Venta: una línea de presupuesto SOLO puede pertenecer a un presupuesto. Además a cada una de las líneas SOLO se le puede asignar un artículo y estará asignada a un contacto (por lo general al contacto del presupuesto de venta).
  • Tabla Artículos: para finalizar el planteamiento, un artículo estará incluido en una línea de presupuesto pero el mismo artículo puede estar en múltiples líneas.

Ya hemos “diseccionado” como queremos que sea nuestra aplicación en nuestra mente (o en un papel). Vamos a ver como podemos responder a la siguiente cuestión: ¿Como relacionamos las tablas en Velneo?.

Realizándonos las preguntas correctas en Velneo para obtener las relaciones entre tablas

Hay dos preguntas básicas a las que deberemos responder para obtener las relaciones entre tablas:

  • “El/La (Tabla_1) del (Tabla_2)”: En este caso, la “Tabla_1” será maestro de la “Tabla_2”.
  • “Los/Las (Tabla_1) del (Tabla_2)”: En este caso, la “Tabla_1” será plural de la “Tabla_2”.

Vamos a verlo contestando a las preguntas con las tablas de nuestro ejemplo:

  • Relación Contactos-Direcciones: “El contacto de la dirección” sería la pregunta correcta a resolver y no “Los contactos de la dirección” puesto que hemos definido que cada dirección sólo tendrá un contacto. Además también se cumple la segunda pregunta “Las direcciones del contacto“. Parece claro pues que contactos será maestra de direcciones y que direcciones será plural de contactos.
  • Relación Contactos-Presupuestos: “El contacto del presupuesto” sería la pregunta correcta a resolver y no “Los contactos del presupuesto” puesto que hemos definido que cada presupuesto sólo tendrá un contacto. Además también se cumple la segunda pregunta “Los presupuestos del contacto“. Parece claro pues que contactos será maestra de presupuestos y que presupuestos será plural de contactos.
  • Relación Contactos-Formas de pago: “La forma de pago del contacto” sería la pregunta correcta a resolver y no “Las formas de pago del contactos” puesto que hemos definido que cada contacto sólo tendrá una forma de pago. Además también se cumple la segunda pregunta “Los contactos de la forma de pago“. Parece claro pues que forma de pago será maestra de contactos y que contactos será plural de forma de pago.
  • Relación Presupuestos-Líneas de presupuesto: “El presupuesto de la línea del presupuesto” sería la pregunta correcta a resolver y no “Los presupuesto de la línea” puesto que hemos definido que cada línea de presupuesto sólo pertenecerá a un presupuesto concreto. Además también se cumple la segunda pregunta “Las líneas del presupuesto“. Parece claro pues que presupuestos será maestra de líneas de presupuesto y que líneas de presupuesto será plural de presupuestos”.

A partir de responder a estas simples preguntas, podéis ir construyendo la relación entre tablas en vuestra aplicación, creando los enlaces a maestro en las tablas correspondientes.

Velneo se encargará de crear el índice correspondiente al campo creado y los enlaces al plural. ¡¡ OJO !! si copiamos el campo de otra tabla, no se creará el indice.

Por ejemplo, en la tabla de presupuestos de venta hemos creado, entre otros, los siguientes enlaces a maestro:

Relación entre tablas: maestros

 

Espero que respondiendo a estas simples preguntas, seas capaz de montar las relaciones entre tablas de tu aplicación.

Ya sabes que si tienes alguna duda sobre Velneo, puedes hacérmela llegar a través del formulario de contacto e intentaré responderla.

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Consultorio Velneo: Relaciones entre tablas aparece primero en AyudaVelneo.

¿Sabes cómo ampliar la información de tus tablas sin tocar su estructura? La solución se llama maestro de extensión.

Comienzas a utilizar Velneo para tus desarrollos y decides utilizar como base de tus aplicaciones, por ejemplo, la open app vErp. Quieres aumentar sus prestaciones sin tocar la base… y comienzan los sudores fríos ¿ahora qué? ¿cómo lo hago? Tranquilo… La solución está en el maestro de extensión.

Maestro de extensión

Al final lo que nosotros queremos es crear nuevos módulos para resolver nuestras necesidades a partir de apps de otras empresas o desarrolladores, sin tocar su estructura, para beneficiarnos de futuras actualizaciones.

La idea es heredar esa app en nuestra solución y utilizar los mecanismos que nos proporciona Velneo para ampliar las funcionalidades que “vienen de serie” en dichas apps.

A nivel de proyectos de aplicación lo tenemos solucionado gracias a la herencia inversa mediante los puntos de inserción y las inserciones de ficha.

A nivel de proyectos de datos tenemos la solución gracias al maestro de extensión.

Pero ¿qué es un maestro de extensión?

El maestro de extensión no es mas que otro tipo de tabla de las que disponemos en Velneo, con unas ciertas particularidades:

  • Es una tabla maestra que necesita de una tabla padre ampliando su información.
  • Sólo se puede crear una tabla maestro de extensión de tablas de tipo maestro normal con clave numérica o maestro normal con clave arbolada. En esta versión (Velneo 20.1) no es posible crear tablas de extensión de tablas submaestras ni históricas ni de otros maestros de extensión.
  • El campo ID del maestro de extensión es un campo de tipo enlace a maestra. Una tabla padre podremos verla como la suma de sus campos y de los que contienen la o las tablas de extensión asociadas.
  • Cuando creamos una tabla de extensión de una tabla padre, Velneo creará en la tabla padre un campo puntero automático hacia el registro del maestro de extensión que compartirá el mismo código (Valor del campo ID). A través de estos podemos obtener los datos de las tablas de extensión de la misma forma que lo hacemos con los punteros a maestro.
  • Al crear la tabla a través del asistente, se generarán los índices complejos NAME, WORDS Y PARTS para poder buscar registros de esta tabla de extensión por los índices correspondientes de la tabla de datos padre.
  • Las tablas de extensión se comportan a nivel de base de datos como una extensión de la tabla padre, por ese motivo Velneo automáticamente añade al maestro de extensión los enlaces plurales de la tabla a la que extiende. Esto permite que podamos navegar directamente a registros históricos de la tabla padre desde la tabla de extensión sin necesidad de realizar una navegación intermedia. En la versión actual (Velneo 20.1) la navegación directa desde el maestro de extensión a los plurales de la tabla padre solamente es funcional cuando la tabla padre y el maestro de extensión están en el mismo proyecto. Si están en proyectos diferentes, para hacer la navegación tendremos que leer el maestro y desde allí cargar los plurales. (Nota extraída de la ayuda de Velneo)

Utilidades del maestro de extensión.

Hay tres situaciones en las que nos puede venir de perlas hacer uso de una tabla de tipo maestro de extensión:

  • Añadir campos a una tabla de una Open App: es el ejemplo típico y mas conocido para el uso de este tipo de tablas. He heredado una open app y no quiero tocar su estructura para beneficiarme de futuras actualizaciones. Es el ejemplo que veremos mas abajo, ampliar la información de la tabla “Contactos” de vErp con datos para un CRM.
  • Reducir el tamaño del registro de una tabla: en algunas ocasiones puede que nos resulte útil crear un maestro de extensión de alguna de nuestras tablas (situada en el mismo proyecto de datos o no). Si la longitud del registro es elevada (recuerda que es una propiedad de la tabla) o si la tabla en cuestión tiene muchos campos que no se usan habitualmente una buena práctica es crear un maestro de extensión.
  • Tablas polimórficas: no es un tipo de tabla como tal. Imaginad que tenemos en una tabla de contactos diferentes tipos: clientes, proveedores, vendedores, transportistas, etc. En lugar de añadir en la tabla de contactos campos específicos para cada uno de los tipos (que no se usarán a no ser que se marque que es de un determinado tipo), podemos crear tablas de extensión para cada uno de los tipos con sus campos específicos.

Ya sabes… no sólo sirven para ampliar la información de una open app.

Creando una tabla maestro de extensión.

Vamos a ver un ejemplo de cómo crear un maestro de extensión en una solución vCrm que hereda de vErp.

Para el ejemplo vamos a crear una tabla que extienda la información de la tabla “Contactos” de vErp añadiéndole campos específicos para el módulo CRM.

  • Pulsamos sobre el asistente de creación de tablas, le asignamos el nombre singular y plural y le indicamos que es de tipo “Maestro de extensión.

Asistente de maestro de extensión I

  • En en siguiente formulario del asistente le indicamos la tabla a la que extiende y además tenemos la posibilidad de marcar si queremos que nos cree los índices complejos NAME, WORDS Y PARTS.

Asistente maestro de extensión II

  • Los dos siguientes formularios del asistente son los típicos para la creación de una tabla maestra: si queremos añadirle los campos estándar y si queremos enlazar con alguna tabla maestra.
  • Sólo faltaría añadir en la tabla los campos que necesitamos para ampliar la información de la tabla de “Contactos” de vErp. En mi caso, he añadido los siguientes campos:

Maestro de extensión vCrm

En esta imagen podéis ver los enlaces plurales que ha creado Velneo automáticamente a la hora de dar de alta el maestro de extensión.

Ya sólo nos faltaría ponerlo en práctica y crear los objetos visuales para mostrar los datos del maestro de extensión…. pero eso lo dejamos para un próximo artículo

¿Has creado ya maestros de extensión en tus aplicaciones?

¿No?

Y a qué esperas para hacerlo, ¿te siguen quedando dudas?

Déjame un comentario mas abajo e intentaré resolverlas.

La entrada ¿Sabes cómo ampliar la información de tus tablas sin tocar su estructura? La solución se llama maestro de extensión. aparece primero en AyudaVelneo.

Sabías que (2) …

Vamos con una nueva entrega de nuestro mítico juego… “Sabías que“.

Por si te perdiste la primera parte del juego y quieres ganar el primer “quesito” del trivial, aquí te dejo el enlace ¿Sabías que?… Parte 1

¿Sabías que..?

¿Sabías que se puede ocultar la Barra de Estado con un comando nativo de Velneo?

    • Usar el comando Interfaz: Ocultar (STATUS_BAR).
    • Podemos usarlo al inicio de la Aplicación en el evento POS_INI del marco Autoexec.
    • También disponemos de la función del API theMainWindow.hideStatusBar().

¿Sabías que a veces los comandos Else y Else if no funcionan correctamente porque …?

    • Los comandos de instrucción Else y Else if siempre deben estar precedidos de un comando If o Else if. Los comandos If y Else if deben estar situados al mismo nivel y no puede haber ninguna otra línea al mismo nivel entre ambos, ni siquiera un Rem.

¿Sabías que se puede convertir un control de puntero a maestro en un control de edición alfabética?

    • El control de edición del puntero a maestro tiene un comportamiento especial para permitir el Autocompletado o la selección de un registro desde la Vista de datos.
    • Si solo nos interesa mostrar el Nombre del maestro como un control de edición alfabética añadimos el string vacío “” al contenido del campo.
      Por ejemplo el contenido   “” + #PUNTERO_MAESTRO.NAME  hará que las propiedades Autocompletar y Tipo de botones desaparezcan.
      Fijando a 1 el valor de la propiedad Solo lectura conseguimos un control no editable.
    • Recordad que la clase VBoundFieldEdit representa al control de edición de puntero a maestro y la clase VLineEdit al control de edición alfabética.

¿Sabías que se puede determinar el tamaño de los iconos del objeto de lista ListView?

    • El tamaño de los Iconos en un objeto de lista ListView se determina con el tamaño del Dibujo del proyecto que asignamos a la propiedad Icono nulo.
    • Añade al proyecto un objeto Dibujo y ponle un tamaño con el editor (por ejemplo 150x100px) y lo asignas a la propiedad Icono nulo del ListView.

¿Sabes cuándo se calculan por primera vez los valores iniciales de los campos de una Tabla?

    • Desde un formulario se calculan siempre en primer plano.
    • En el plano que corresponda cuando se ejecuta el comando Crear nueva ficha en memoria.
    • La función del API VRegister.setTable() es la que ejecuta los valores iniciales. Tenedlo en cuenta en los bucles que añaden registros a una tabla.
    • Crear Copia de ficha en memoria no ejecuta valores iniciales. Podemos usar el comando Calcula campos dependientes, pero solo funciona con fórmulas que contienen campos de la tabla.
    • Los Tubos de ficha o lista no ejecutan los valores iniciales. Solamente se ejecutan los valores iniciales que dependan de otros campos de la tabla de destino

¿Sabes el orden de las señales cuando se han definido mas de una vez sobre el mismo control?

    • Un objeto de lista del proyecto con una conexión de evento Cambio de seleccionado se incrusta en un control Vista de datos del formulario.
    • En el control Vista de datos definimos la misma conexión de evento Cambio de seleccionado.
    • Se ejecutarán los 2 manejadores de evento, pero siempre primero el manejador de evento del objeto del proyecto.
    • De esta forma podemos tener funcionalidad común en el objeto del proyecto (por ejemplo guardar el ID seleccionado) y en los distintos formularios disparar una conexión de evento con un manejador de evento personalizado cuya primera línea podrá ser

Interfaz: Get variable local de vista de datos (CTR_LISTA, NID_FICHA, NID_FICHA_LISTA)

La variable local de la Vista de datos NID_FICHA tendrá un valor fijado previamente por la conexión de evento del objeto de lista.

¿Sabías que VReport SOLO tiene acceso al proyecto de datos?

    • Desde el editor de fórmulas de VReport solo tenemos acceso a los controles del proyecto de datos de la tabla de entrada (funciones, constantes, variables globales, …)

¿Sabías que un proceso ejecutado desde un formulario recibe como entrada la ficha en memoria que está en Alta o Modificación?

    • El comando Ejecutar proceso ejecutado desde un manejador de evento o desde un botón del formulario pasa como entrada la Ficha que tenemos en memoria en Alta o Modificación.
    • Por lo tanto podemos modificar los campos de la Ficha en memoria sin generar nueva transacción (equivale al comando Pedir formulario).
    • ¡¡Ojo!! no es lo mismo que ejecutar los comandos Crear manejador de objeto, Añadir ficha al objeto y Disparar objeto. En este caso lo que pasamos al proceso es la ficha en disco.

¿Sabías que puedes aplicar formato HTML/CSS a los controles de Texto estático en los formularios?

    • La propiedad Nombre de los controles de tipo Texto estático aceptan código HTML/CSS que se interpreta en tiempo de diseño y en ejecución.
      Un ejemplo de lo que se puede conseguir se muestra en la captura siguiente. Encima de cada Texto estático aparece el contenido de la propiedad Nombre.

VAF_S2_HTML

    • Como se puede ver podemos usar directamente Titulares H1, H2, …, colorear texto, crear líneas horizontales con un simple <hr>, insertar imágenes desde la carpeta caché o directorio por defecto, subíndices y superíndices.
    • No es una funcionalidad documentada, por lo tanto puede desaparecer en futuras versiones.

Y ahora confiesa… ¿cuántas sabías? 

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Sabías que (2) … aparece primero en AyudaVelneo.

Modelo de datos abstracto

Un modelo de datos es un lenguaje orientado a hablar de una base de datos, que permite describir las estructuras, las restricciones de integridad y las operaciones de manipulación de los datos.

En este artículo nos vamos a centrar en el “modelo de datos abstracto”

Si te has perdido el primer post de esta serie, te recomiendo leerlo antes de continuar…

¿Seguro que lo has leído ya?

Pues continuamos.

Modelo de datos abstracto

¿Qué es un modelo de datos abstracto?

Cada una de las tablas de nuestra aplicación se divide en:

  • Registros: Tipo de información que vamos a almacenar en nuestra tabla
  • Campos: Propiedades del mismo tipo de cada uno de los registros que forman un registro
  • Índices:  Estructura de datos que mejora la velocidad de las operaciones, por medio de identificador único de cada fila de una tabla, permitiendo un rápido acceso a los registros.

Aplicando la “teoría del kiwi“, que mas da que sean clientes, que proveedores, que contactos, que vendedores, que …. Al final todos estos tipos (registros) tendrán unas propiedades (campos) comunes.

Por lo tanto podemos crear una tabla común (“Entidades”) que englobe a todos ellos.

Puestos a abstraer…

  • ¿Qué diferencia hay entre las líneas de un presupuesto y las líneas de un pedido?
  • ¿Qué diferencia hay entre las líneas de un albarán de venta y las líneas de una factura de venta?
  • ¿Qué diferencia hay entre las líneas de un albarán de compra y una factura de compra?
  • Y ¿entre un cobro y un pago?

Si os fijáis, no me he referido en ningún momento a los datos que guardamos (registros) si no a las propiedades que tienen (campos).

Ventajas e inconvenientes de este modelo de datos

Como casi todo es relativo… este modelo de datos también tiene sus ventajas y sus inconvenientes. Vamos a verlas tomando como ejemplo la tabla de “Entidades“:

Ventajas del modelo de datos abstracto

Evitamos tener duplicada la información. Si, por ejemplo, una entidad es de tipo cliente y además nos vende, no tendremos que volver a dar de alta toda su información para que también sea proveedor. Tendremos que ser nosotros como programadores los que dotemos a las aplicaciones de los mecanismos para diferenciar los distintos tipos de registros que guardaremos en la tabla.

Creamos campos en el proyecto de datos una sola vez. Al tener una sola tabla (por ejemplo de entidades) si añadimos un nuevo campo, ya estará accesible para los distintos tipos que tengamos en la tabla (por ejemplo un nuevo teléfono).

Creamos objetos en el proyecto de aplicación una sola vez. Es probable que tengamos el mismo formulario de edición para todos los tipos de entidad. Por lo tanto si añadimos un nuevo campo (el ejemplo de un nuevo teléfono) , con crearlo en un único formulario bastará.

Inconvenientes del modelo de datos abstracto

Creación de mas índices en la tabla. Por lo tanto las reindexaciones consumirán mas tiempo. Al tener todas las entidades en la misma tabla, a nivel de datos las tendremos que tener diferenciadas para cuando nos pidan la información.

Mas registros en la misma tabla. Al tener los datos del mismo tipo almacenados en la misma tabla, habrá mas registros por tabla. En entidades no resulta problemático pero ¿y en líneas de documentos?.

Peligro de superar la longitud máxima recomendable del registro. La longitud recomendada para los registros está fijada en 4000 bytes... aunque siempre podemos utilizar tablas de extensión.

Consideraciones a tener en cuenta a nivel de tabla

Como hemos dicho anteriormente,

en este modelo de datos, debemos ser nosotros como programadores los que deberemos crear los mecanismos para diferenciar la información que guardamos en las distintas tablas.

Siguiendo con el ejemplo de la tabla de “Entidades“, vamos a ver  como podemos crear estos mecanismos.

Campos a crear en la tabla

Para diferenciar los distintos tipos de entidad que guardaremos en la tabla, tendremos que crear un campo booleano por cada uno de los tipos. Esta es la estructura de campos para los tipos de entidad en vErp:

Campos para el modelo de datos abstracto

 

Además a nivel de tabla, también tendremos que encargarnos de crear los distintos índices para que el usuario pueda obtener los datos por tipos de entidad:

Ïndices en modelo de datos abstracto

 

En este caso hemos creado un índice por id, nombre, palabras y trozos por cada uno de los distintos tipos de entidad que vayamos a tener en nuestra base de datos.

Consideraciones a tener en cuenta a nivel de objetos de interfaz

Ya que estamos…. ¿por qué no facilitarles la vida a nuestros usuarios?

Vamos a proporcionarles las herramientas para que puedan obtener la información por los distintos tipos de entidad que hayan guardado.

A nivel de proyecto de aplicación, esto lo conseguimos por medio de los localizadores:

Localizadores en modelo de datos abstracto

 

En este caso hemos creado un localizador por cada uno de los tipos de entidad que tenemos y en cada uno de ellos, le hemos añadido los índices correspondientes creados anteriormente. De este modo podemos añadir acciones para que el usuario además de obtener los datos generales de todas las entidades, pueda localizar los datos de un tipo concreto.

¿Se te ocurre alguna ventaja o algún inconveniente mas de este modelo de datos? 

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Modelo de datos abstracto aparece primero en AyudaVelneo.

Introducción al modelo de datos en Velneo

Nos encargan un nuevo desarrollo abrimos vDevelop y, sin pensar en qué  modelo de datos vamos a utilizar, nos ponemos a escribir código como si no hubiese un mañana.

¿Has solucionado el problema que tienes que resolver?

¿Sabes ya qué relación hay entre las tablas?

Introducción al modelo de datos

Definición de modelo de datos

Según la Wikipedia:

Un modelo de datos es un lenguaje orientado a hablar de una base de datos, que permite describir las estructuras, las restricciones de integridad y las operaciones de manipulación de los datos.

Velneo nos proporciona una herramienta muy valiosa, y me atrevería a afirmar que muy poco utilizada, para describir las relaciones entre las tablas de nuestra base de datos: el objeto esquema.

Objeto esquema

Además el “lenguaje natural” también nos ayuda a definir estas relaciones entre las tablas de nuestro modelo de datos, sobre todo para saber si un dato es maestro o plural:

  • Para definir los plurales de un maestro, utilizaremos la frase “los/las….. del……..”
    • Los albaranes del cliente
    • Las direcciones del contacto
    • Las líneas del pedido
  • Para definir el maestro de los plurales, utilizaremos la frase contraria “el …. del….
    • El cliente de la factura
    • El artículo de la línea de pedido
    • El proveedor de la compra.

¿Modelo de datos concreto o abstracto?

Jorge Hontoria hacía una interesante reflexión sobre cuál es el mejor modelo de datos. Como siempre digo… pues depende.

Antes de comenzar con el modelo de datos, tendremos que dar respuesta a una serie de preguntas.

Vamos a ver un ejemplo, centrándonos en las entidades de nuestra aplicación.

  • ¿Nuestra aplicación va a servir de base para que otras apps la hereden? (ejemplo vErp)
  • ¿Es una aplicación para un departamento de una empresa?
  • ¿Vamos a crear un vertical?
  • ¿Será una solución de tipo mixto?

Modelo de datos abstracto (vErp)

Esta es la estructura de las entidades en vErp:

Modelo de datos vErp

  • En la tabla de contactos, tenemos topos los posibles tipos de entidades que necesitemos: clientes, proveedores, transportistas, contactos, etc. etc. (en próximos artículos veremos esta estructura con mas detalle).
  • En la tabla de direcciones (plural) tendremos las direcciones de cualquier tipo de contacto.
  • Esta solución, como hemos dicho servirá de base para otras apps. Por lo tanto si la heredamos, en la solución de nivel superior tendremos que añadir los campos específicos de las entidades para ese módulo. Si creamos una solución de CRM que herede vErp, tendremos que extender la funcionalidad de la tabla “Contactos” en dicho módulo.

Modelo de datos vErp + CRM

Modelo de datos concreto

Vamos a ver ahora un ejemplo del caso contrario:

Modelo de datos concreto

  • En este caso, he creado una tabla por cada uno de los tipos de entidad que voy a tener en mi aplicación.
    • Una tabla para Clientes
    • Una tabla para Vendedores
    • Una tabla para transportistas
    • Una tabla para Proveedores
  • Después, en lugar de crear una tabla de direcciones por tipo de entidad, he creado una sola tabla que sea plural de todas las anteriores.
  • Lo mismo para los ficheros adjuntos y los contactos.

En próximos artículos veremos estas estructuras en detalle.

¿Qué modelo de datos es el que utilizas tu? ¿Cuál te parece mas sencillo?

Déjame un comentario mas abajo y comenzamos el debate.

La entrada Introducción al modelo de datos en Velneo aparece primero en AyudaVelneo.

Proyectos en Velneo: ¿Cómo estructurarlos?

Cuando comenzamos a desarrollar con la plataforma, una de las primeras cuestiones a resolver es la de cómo estructurar los proyectos en Velneo. Pues como diría un buen gallego: “depende”.

En el post “¿Cuántos proyectos debe tener mi solución?” vimos que lo mas recomendable, es tener un solo proyecto de datos y un solo proyecto de aplicación.

En el post de hoy vamos a ver las ventajas y los inconvenientes de distintas formas de estructurar los proyectos en Velneo.

Estructurar los proyectos en Velneo

 

Tipos de estructura de proyectos en Velneo

Para saber la estructura que tienen que tener los proyectos, y por consiguiente nuestras soluciones, tendremos que responder a una serie de preguntas. Entre ellas podemos destacar las siguientes:

  • ¿Mi aplicación va a ser heredada por otras soluciones?
  • ¿Quiero facilitarle la vida a otros desarrolladores?
  • ¿Cómo voy a distribuir mi solución? ¿Como un todo?, ¿Por módulos?
  • ¿Quiero que mi solución sea la base de otras soluciones?
  • ¿Quiero tener distintas instancias por módulo. o una instancia para todos los módulos?

En función de lo que contestemos, tendremos que estructurar nuestros proyectos.

Proyectos “Monolíticos”

Son aquellas soluciones que tienen un proyecto de datos y un proyecto de aplicación. Un ejemplo de esta estructura de proyectos en Velneo es mi aplicación GTDenlanube.

Proyectos en velneo: Estructura monolítica

Estructura monolítica

Ideal cuando empezamos a desarrollar con Velneo V7. Evitamos complejidad.

Nos despreocupamos de crear tablas de extensión y herencia inversa.

Facilitan la herencia a otros desarrolladores.

No se puede trocear.

Dificulta el desarrollo colaborativo.

No es escalable al estar todos los módulos en el mismo proyecto.

Todo el peso está en la misma solución, con altos consumos de memoria a medida que añadimos funcionalidades. Si tuviesemos un ERP + CRM + TPV + CONTABILIDAD, tendríamos en una solo instancia todos los objetos... ahora imaginad mas módulos: cartera, producción, etc etc.

 

Proyectos “Verticales”

Son aquellas soluciones que tienen un proyecto de datos y varios de aplicación. Un ejemplo muy claro lo tenemos el vErp

Proyectos en Velneo: Verticales

Ya tenemos dos proyectos de aplicación perfectamente diferenciados: vTPV y vERP. Por lo tanto podemos instanciar por separado... aunque los datos siguen estando en la misma instancia.

Facilitan a los desarrolladores las personalizaciones sencillas

Los datos siguen estando en el mismo proyecto.

No es escalable

Proyectos “Horizontales”

Son aquellas soluciones que tienen varias soluciones independientes relacionadas por un proyecto que las hereda. Un ejemplo muy claro lo tenemos en los módulos de la plataforma PaaSOS de Tipesoft. Los módulos de PaaSOS tienen un único proyecto de datos y uno de aplicación…. heredando de un núcleo común (veremos este montaje “mixto” a continuación).

Proyectos en Velneo: Horizontales

Módulos completamente independientes.

Perfectamente escalables.

Peso de las soluciones repartido evitando consumos de memoria desmedidos.

Facilita la extensión de nuestras soluciones.

Facilita el desarrollo colaborativo.

Complejidad en la visibilidad de los datos. Unos módulos no tienen "conocimiento" de los datos de su solución hermana.

Imposible la herencia entre soluciones "hermanas". Si es posible mediante la API de Velneo.

Si queremos utilizar varias soluciones, tendremos que "empaquetarlas" en distintos packs.

Proyectos “Mixtos”

Son aquellas soluciones, generalmente de tipo Monolítico que heredan otras soluciones (del tipo que sean). Son aquellas soluciones que creamos para no tocar o ampliar la solución base y poder beneficiarnos de futuras actualizaciones de dicha solución: soluciones que creamos heredando vERP, soluciones que creamos heredando el núcleo de PaaSOS

Proyectos en velneo: Mixtos

Facilitan la instalación de nuevas versiones de nuestra solución base.

Perfectamente escalables.

Facilitan la extensión de la solución.

Facilitan el desarrollo colaborativo.

Complejidad en la herencia de soluciones.

No están recomendados para usuarios que comienzan con la plataforma. Necesitan conocimiento de estructuras avanzadas en Velneo V7.

 

¿Ves alguna ventaja o inconveniente mas en la forma de estructurar nuestros proyectos en Velneo?

Coméntame tu experiencia mas abajo.

La entrada Proyectos en Velneo: ¿Cómo estructurarlos? aparece primero en AyudaVelneo.

¿Sabes utilizar los tipos de índices en Velneo V7?

Sabes que ha llegado el momento de definir y configurar correctamente los índices en Velneo V7 cuando ejecutas tu aplicación y notas que hasta que se cargan los datos, te da tiempo a tomarte un café.

Continuando con la serie que comenzamos con los tipos de tabla y tipos de campo, hoy vamos a continuarla con los tipos de indice que podemos definir en nuestras aplicaciones. Recordad que esta serie sobre la base de datos en Velneo V7 se complementa con el artículo en el que tratamos las actualizaciones y los triggers.

Índices en Velneo V7

¿Qué son y para qué sirven los índices en Velneo V7?

Según la definición de Velneo:

Se trata de una estructura de datos que mejora la velocidad de las operaciones, permitiendo un rápido acceso a los registros de una tabla. Un índice puede estar compuesto por uno o varios campos, por fórmulas o por una combinación de ellos. A cada uno de estos componentes del índice se le llama parte.

Cómo crear los índices en Velneo V7

Para crear un índice en nuestras tablas, tenemos 3 formas de hacerlo:

  • Desde la toolbar superior de la tabla:
    Toolbar índices en VelneoEn este caso debemos pulsar el icono de la flecha hacia la derecha para crear un nuevo índice o bien seleccionando un campo y pulsando el icono siguiente con la flecha (ahora desactivado), nos creará un índice de dicho campo.
  • Desde el panel de subobjetos: Tendremos que pulsar sobre el icono con el símbolo + e indicar que queremos crear un índice.Panel de subobjetos en tipos de indice en Velneo V7
  • Pulsando el botón derecho del ratón sobre la tabla en cuestión se nos abrirá el menú contextual para poder crear nuevos objetos en dicha tabla.

Identificadores de índices en Velneo V7

A la hora de definir un índice, hay que tener en cuenta una serie de consideraciones con los identificadores:

  • El identificador: identifica de forma unívoca un índice dentro de una tabla. Este identificador lo utilizaremos en fórmulas o en aquellos sitios donde tengamos que resolver un índice.
  • El identificador constará de mayúsculas y números exclusivamente. Al identificar de forma unívoca un campo de una tabla no puede haber duplicidad.
  • Los identificadores ID y NAME son palabras reservadas: El identificador ID referencia el índice que es clave primaria de la tabla e identifica unívocamente cada registro. No debemos alterar este identificador si no queremos perder la funcionalidad implícita, aunque si podemos modificar sus descriptores, la propiedad Nombre (cita de la ayuda de velneo).

Tipos de índices en Velneo V7

El tipo de índice nos va a permitir definir de que forma van a ser indexados los datos en nuestras tablas. Los tipos de índice de que disponemos son:

  • Clave única: Cada registro tendrá un identificador único. Con este tipo de índice, Velneo no va a permitir registros duplicados.
  • Palabras: Velneo va a indexar en el índice las palabras que el usuario introduzca en las partes definidas en el índice. Por razones de optimización y rendimiento, solamente se indexarán los 9 primeros caracteres de cada palabra del campo o campos a indexar.
  • Múltiples claves: El registro es indexado desde cero claves hasta el número que el programador declare en la propiedad “Número de claves“. Los campos a indexar han de ser del mismo tipo y longitud.

    Un ejemplo muy claro para la utilización de este tipo de índice sería: Hemos creado en la tabla de entidades 3 campos para introducir los distintos teléfonos que puede tener dicha entidad (Móvil, Trabajo y Particular). Pondremos como partes del índice estos campos y cuando el usuario introduzca un determinado teléfono, el sistema lo buscará en cualquiera de estos tres campos.

  • Acepta repetidas: La ficha es indexada sólo una vez pero, al contrario que la clave única, se admiten repeticiones.
  • Trozos de palabras: El registro es indexado por cada grupo de 3 ó más caracteres de cada una de las partes que forman la clave.

Partes de índices en Velneo V7

Un índice estará compuesto por una o más partes. Para crear una parte de un índice pulsar el botón Subobjeto parte del índice de la barra de herramientas o abrir el menú “Objetos“, submenú “Nuevo sub-objeto“, opción “Parte índice“.

La propiedad “Modo” nos permitirá establecer de que forma se indexara la parte del índice. Sus posibles valores son:

  • Campo completo: La parte a indexar va a ser un campo y se indexará completo.
  • Campo porción: La parte a indexar va a ser un campo pero va a indexarse solamente una porción del mismo.
  • Fórmula: La parte a indexar va a ser una fórmula definible por el programador.

* NOTA *: Si el modo es Campo porción y el campo es de tipo alfabético ; en esta propiedad podremos hacer una conversión de la parte a una tabla de caracteres inferior.

Ejemplo: un campo de tipo alfa256 indexarlo convertido a alfa 64.

Consideraciones a tener en cuenta con los índices en Velneo V7

Podemos optimizar nuestra base de datos siguiendo una serie de recomendaciones muy sencillas:

  • 1.- Siempre será más óptimo un índice de “Clave única” que un índice de “Acepta repetidas”. Para convertir un índice de tipo “Acepta repetidas” en un índice de “Clave única”, bastará con añadirle el campo ID y cambiarle el tipo.
  • 2.- Los índices menos óptimos son los de tipo “Trozos” y tipo “Palabras”. Lógico. Velneo tiene que indexar todas las palabras de todos los registros para encontrar las palabras o trozos coincidentes.
  • 3.- Podemos mejorar el rendimiento de los índices en Velneo si en lugar de crear un índice por cada campo, agrupamos los campos a buscar en un solo índice. Es decir, si queremos buscar un dato en distintos campos (por ejemplo dentro del campo “Name”, dentro del campo “Descripción” y dentro del campo “Observaciones”) siempre será mas óptimo que creemos un indice con 3 partes (una por cada campo) que 3 índices (uno por cada campo).

Espero que después de aplicar todos estos consejos sobre los tipos de índices en Velneo V7, tus aplicaciones vuelen. Ya sabes que valoro tus opiniones sobre los artículos… puedes dejarla mas abajo en los comentarios.

La entrada ¿Sabes utilizar los tipos de índices en Velneo V7? aparece primero en AyudaVelneo.