No tengo tiempo para iniciarme en Velneo

Hace unos días realicé una encuesta a los suscriptores para saber cual era su principal problema a la hora de desarrollar con la plataforma. Uno de los problemas mas repetidos era “No tengo tiempo para iniciarme en Velneo“.

Resulta curioso que el principal problema no sea como crear vistas de datos, como lanzar las búsquedas o como utilizar los enlaces indirectos.

El principal problema es el tiempo.

 

iniciarme en velneo

La verdad es que no se como me sorprende.

En esta sociedad en la que vivimos se da una paradoja muy interesante en las empresas de programación:

el principal bien que tenemos es el tiempo… y nos dedicamos a programar a toda prisa nuevas funcionalidades en nuestras aplicaciones sin pararnos a pensar si el desarrollo que estamos realizando es realmente necesario para nuestros clientes.

Me pasa incluso a mi. Llevo queriendo sacar tiempo para empezar a desarrollar en QML ya ni me acuerdo desde cuando… y la semana pasada tampoco lo conseguí.

Si no lo habéis hecho todavía, os aconsejo leer este post de Alfonso Gutiérrez. Es para pensar y reflexionar sobre ello.

Causas de la “escasez de tiempo”

La gran mayoría de los que desarrollamos en Velneo somos pequeñas empresas o autónomos. No tenemos grandes departamentos en nuestra empresa de ventas, contabilidad ni de programación.

Estoy convencido de que una de las principales causas de la escasez de tiempo que impide “iniciarme en Velneo” es el “síndrome del hombre orquesta“: como voy a dejar que otro haga esto.. si yo soy el que mejor lo hace.

Gran error.

Yo facturo, yo vendo, yo me encargo de la contabilidad, yo programo, yo hago las nóminas, etc etc etc. y al final no tengo tiempo para lo importante.

Tener tiempo para pensar que vamos a desarrollar en las aplicaciones para hacer rentables nuestras empresas.

Si te sirvo de ejemplo, te voy a contar 4 medidas que he tomado para “ganar tiempo”:

  • Contratar una asesora: Lo siento no soy contable ni asesor fiscal. En España hay demasiados trámites burocráticos y cada 3 meses hay que presentar impuestos. Susana se encarga de todo esto. Es lo primero que hice cuando me decidí a ser autónomo hace ya algunos años. No me arrepiento en absoluto… es mas cada 3 meses me compadezco de ella.
  • Contratar un diseñador para la web: la primera versión de la web la desarrolle, la instalé y la configuré yo. Cuando decidí que era hora de actualizarla por completo (con el aspecto que ves ahora) lo primero que decidí es que no la iba a hacer yo (y se hacerlo puesto que ya lo había sufrido una vez). Otra decisión acertada. En este caso fue mi amigo Dan quien se encargó de ello.
  • Aprender a decir NO y rechazar algunos trabajos: antes decía a todos los trabajos que me llegaban que si. No me preocupaba si “eran rentables” sólo me preocupaba “poder facturar“. Si te fijas acabo de hacer una comparación muy sutil pero bastante importante “rentabilidad vs facturación“. Ahora sólo cojo trabajos que van a ser rentables.
  • Externalizar todos los trabajos mecánicos que tengas en tu empresa. El tiempo que ganarás compensará con creces la inversión que tengas que realizar.

La cuenta es muy sencilla. Ponte un precio/hora (el precio que quieres ganar por tu trabajo). Mira las horas que inviertes en trabajos mecánicos o trabajos que podrías delegar. Multiplica tu precio hora por esas horas que empleas en trabajos que podrías delegar. Y ahora mira cuanto te costaría delegar esos trabajos. ¿Te compensa? A mi te aseguro que si.

Consejos para “iniciarme en Velneo”

El primer consejo que te daría es que comiences poco a poco (vamos, que no quieras desarrollar un ERP el primer día… ni siquiera el segundo jejeje) y sobre todo que te comprometas.

Trata tu formación en Velneo como si de un proyecto de unos de tus clientes se tratase. Resérvate horas en tu planificación semanal. Será la única forma de que avances.

Puedes comenzar con estos post que he seleccionado para “Comenzar con el desarrollo en Velneo“.

Después puedes realizar algún curso online gratutio como este o de pago como el programa formativo “Despega con Velneo V7“.

Por último si no consigues comprometerte con la formación, lo mejor que puedes hacer es un curso presencial. De esta forma te comprometes si o si.

Repite conmigo “voy a iniciarme en Velneo”.

¿Qué medidas vas a tomar para conseguirlo?

Cuéntamelas dejándome un comentario mas abajo.

 

La entrada No tengo tiempo para iniciarme en Velneo 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.

Las 3 únicas formas de ampliar las funcionalidades de Velneo vErp

Hay una pregunta recurrente en los clientes que contratan tanto el “Bono de 10 horas de desarrollo” como el “Servicio de desarrollo online“:

“¿Cuál es la mejor forma de ampliar las funcionalidades de Velneo vErp para mis desarrollos?”

Las 3 únicas formas de ampliar las funcionalidades de Velneo vErp

 

Además de responder a esta pregunta, surgen otras cuestiones no menos importantes:

  • Si modifico directamente la plantilla, ¿qué pasa cuando Velneo saque una nueva versión?
  • Si heredo la plantilla, ¿cómo integro mis desarrollos?
  • Si parto de una versión de vErp y la modifico según mis necesidades, cuando Velneo saque alguna funcionalidad interesante en posteriores versiones, ¿podré adaptarla a mi vErp?

Vamos a intentar responder a todas estas cuestiones viendo los pros y los contras de cada una de las formas.

Opción 1: Ampliar las funcionalidades de velneo vErp modificando directamente la plantilla

La solución “aparentemente” mas fácil… pero con matices.

Todos los objetos que creemos para añadir las funcionalidades de velneo vErp (o modificarlas), irán en los mismos proyecto de la plantilla.

Si trabajamos con este método, tendremos que tener algún mecanismo para que cuando Velneo lance una nueva versión, podamos añadir las nuevas funcionalidades incluidas sin borrar toda nuestra personalización.

Lo que se hace normalmente es crear una una carpeta (tanto en el proyecto de datos como en el proyecto de aplicación) llamada, por ejemplo, “Personalización”.

Cada objeto que modifiquemos (ya sea del proyecto de datos o del proyecto de aplicación), tendremos que moverlo a esta carpeta “Personalización” ¡sin cambiarle el identificador al objeto!.

Cada objeto nuevo tendremos que moverlo también dentro de esta carpeta.

¿Cómo actuar cuando Velneo lance una nueva versión de vErp?

Tendremos que realizar los siguientes pasos cada vez que Velneo lance una actualización de la plantilla:

  • Abrir 2 vDevelop:
    • En uno tendremos nuestro vErp modificado.
    • En el otro tendremos la nueva versión de vErp.
  • Eliminaremos de la nueva versión todos los objetos que tengamos en nuestra carpeta “Personalización” (tanto en el proyecto de datos como en el de aplicación)
  • Copiaremos nuestra carpeta “Personalización” a la nueva versión de Velneo vErp.
  • Creamos un .vin con la nueva versión y la instalaremos en nuestro servidor de producción.

Sencillo… si tenemos cuidado.

Ventajas

Solución + cómoda técnicamente.

Evitamos el uso de herencia (con otras soluciones) y herencia inversa. + sencillo para los desarrolladores que os estáis iniciando en la plataforma.

Podemos modificar a nuestro antojo los triggers y las actualizaciones de las tablas.

Inconvenientes

Exige un mantenimiento cada vez que salga una nueva versión.

Mayor riesgo de cometer errores. Sobre todo en borrado de objetos

Opción 2: Ampliar las funcionalidades de velneo vErp heredando la plantilla

Solución algo mas compleja que la anterior.

Tendremos que crear una nueva solución que “herede” de Velneo vErp.

En esta nueva solución crearemos todos los objetos necesarios para ampliar las funcionalidades de Velneo vErp.

Ampliar las funcionalidades de velneo vErp heredando la plantilla

Si queremos modificar alguno de los objetos del proyecto de aplicación incluidos en Velneo vErp, tendremos que “subirlo” a nuestra solución (en este caso al proyecto vCrm_app 1.0):

Personalización de vErp

Como podéis ver, he creado una carpeta llamada “Personalización de vErp” en la que voy “subiendo” los objetos que quiero modificar de la plantilla vErp.

Si hay que ampliar la funcionalidad de las tablas de vErp, tendremos que crear “Tablas de extensión” en nuestro nuevo proyecto de datos.

¿Cómo actuar cuando Velneo lance una nueva versión de vErp?

Al no haber tocado ningún objeto de la plantilla Velneo vErp, simplemente instalamos el nuevo .vin y a funcionar.

Ventajas

Solución + sencilla de mantener.

Menor riesgo de cometer errores.

Inconvenientes

Mayor dominio de la plataforma al usar herencia inversa.

No podemos modificar ni ampliar las funcionalidades de los trigger y actualizaciones de las tablas incluidas en Velneo vErp puesto que Velneo no permite herencia inversa en tablas.

Opción 3: Ampliar las funcionalidades de velneo vErp partiendo de una versión de la plantilla

Partimos de una versión de la plantilla vErp y a partir de ahí nos olvidamos de dicha plantilla.

Con esta opción ya podemos jugar con diversas variantes.

A mi personalmente la opción que mas me gusta es tener un “Core” o “Núcleo” común para todos mis desarrollos y a partir de ahí, utilizar de nuevo la “Opción 2” pero con mi “Core” para las distintas personalizaciones sectoriales o de distintos clientes.

Con esta opción modifico y amplío las funcionalidades de mi “Core” sin depender de otras empresas.

¿Cómo actuar cuando Velneo lance una nueva versión de vErp?

Cuando Velneo lance una nueva versión de la plantilla, tendremos que integrar manualmente las funcionalidades que nos sean útiles o necesarias que vengan incluidas en vErp.

Ventajas

Solución completamente adaptada a nuestras necesidades.

No dependemos de Velneo para la corrección de errores o ampliación de nuevas funcionalidades.

Inconvenientes

Perdemos la integración con el ecosistema de aplicaciones de velneo vErp.

Integración manual de nuevas funcionalidades incluidas en la plantilla.

 

¿Con cuál de las 3 formas de ampliar las funcionalidades de vErp te quedas? 

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

La entrada Las 3 únicas formas de ampliar las funcionalidades de Velneo vErp aparece primero en AyudaVelneo.

Vista de datos: el poder de Velneo al alcance de tus listas

Velneo se define como “Plataforma de desarrollo de aplicaciones empresariales”. Al final el usuario quiere ver datos. Estos datos se muestran a través de listas de registros… y aquí es donde se muestra el poder de nuestro control vista de datos.

Vista de datos listas al alcance de tu mano

En post anteriores vimos como podíamos utilizar el control “vista de datos” para mostrar registros dentro de un menú o cómo optimizar la carga de registros en una vista de datos.

Hoy nos vamos a centrar en el propio control “vista de datos”.

Según la definición de Velneo, la vista de datos es un:

Control de Contenedores que permite incluir dentro de un formulario una acción, desde la que podremos disparar objetos de vista de datos, como por ejemplo, rejilla, formulario, multivista, etc.

 En esta definición aparecen dos de los conceptos fundamentales de Velneo:

  • Concepto de flujo (ya vimos este concepto aquí).
  • Concepto de abstracción o diferenciar el qué del cómo es decir, qué queremos mostrar (lista de registros) de cómo lo queremos mostrar (rejilla, formulario multivista, etc).

Vamos a ver como se aplican estos conceptos.

Crear la vista de datos en nuestro formulario

Hemos visto anteriormente, en la definición de la vista de datos, que éste es un control de los que podemos incluir dentro de un formulario.

Antes de crear los objetos necesarios para mostrar los registros, también deberemos tener en cuenta el flujo. Como ya sabemos, un formulario puede pertenecer a una tabla o ser un formulario sin origen. Por lo tanto deberemos tener en cuenta dónde nos encontramos y qué queremos mostrar.

Generalmente necesitaremos dos objetos para mostrar los registros en nuestra vista de datos:

Control vista de datos

  • En la propiedad “Objeto 1” indicaremos qué queremos mostrar (en este caso los registros que devuelve una búsqueda), por lo tanto una lista de registros: n registros, 1 o ninguno, dependiendo de la búsqueda.
  • En la propiedad “Objeto 2” le indicaremos cómo queremos mostrar esos registros. En este caso al ser la salida del “Objeto 1” una lista de registros, podemos seleccionar cualquier objeto de tipo lista de la tabla a la que hace referencia la búsqueda de dicho objeto.

Esta sería la manera mas sencilla de mostrar los registros de una tabla en una vista de datos… pero Velneo tiene sus peculiaridades.

Consejos antes de crear la vista de datos en nuestro formulario

Algunos consejos antes de crear vistas de datos a lo loco.

  • Si tu aplicación va a ser heredada por otras, nunca vas a saber donde se van a utilizar tus formularios… por lo tanto cuidado con la carga de registros.
  • Velneo carga todos los objetos incluidos en un formulario al crearlo. Es decir si tienes un formulario en el que muestras la ficha de un cliente y en ese formulario tienes un separador de pestañas en el que tienes los plurales de pedidos, albaranes y facturas de dicho cliente… todos esos datos, se cargarán al entrar en la ficha… por lo tanto cuidado con la carga de registros.
  • Si tienes un formulario sin origen que actúa como menú y en dicho formulario cargas n vistas de datos con miles de registros y cada una de ellas se resuelve con una búsqueda de varios componentes, también se cargarán todos los registros al entrar al formulario… por lo tanto cuidado con la carga de registros.
  • Siempre hemos dicho que las búsquedas (o procesos que cargan búsquedas), mejor resolverlas en tercer plano (es decir, en el servidor). Hay una salvedad. Si la búsqueda en cuestión es por un único componente, no vamos a notar diferencia de carga entre lanzarla en primer plano o lanzarla en tercer plano. Para todos los demás casos hay que lanzarlas siempre en el servidor.
  • Siempre que podamos utilizaremos la señal “on-show” del formulario para cargar los registros en la vista de datos mediante un manejador de evento.

Espero que con estos simples consejos no tengáis ningún retardo a la hora de mostrar los registros al usuario.

Utilización del control vista de datos a través de ejemplos prácticos

Particularmente siempre he tenido una “guerra” con los usuarios de mis aplicaciones a la hora de mostrar los registros de un determinado módulo. Están (mal)acostumbrados a que a la hora de entrar, por ejemplo en el módulo de clientes (sirve cualquier otro módulo que se te ocurra) a ver la lista de TODOS los clientes…

  • Si no ven la rejilla con datos… parece que no hay datos.
  • Si al final vas a seleccionar uno en concreto… ¿para que mostrar todos?
  • ¿no será mejor que selecciones primero el rango de los que quieran visualizar?

Como los caminos del Señor son infinitos, vamos a ver varios ejemplos con estas casuísticas.

1.- Mostrar en la vista de datos todos los registros de una tabla al entrar en el formulario que hace de menú.

Lo mas sencillo es hacerlo de la siguiente manera:

Hemos creado un proceso sin origen (ya que el formulario era sin origen) y con destino la lista de la tabla que queremos mostrar en la vista de datos.

Las instrucciones que tenemos en el proceso son:

  • Cargar lista de la tabla por el índice que mas nos interese
  • Añadir lista a la salida (el siguiente objeto en el flujo, recogerá la lista devuelta por el proceso).

Lo único que tendremos que hacer ahora es crear la vista de datos. Como “Objeto 1” pondremos este proceso, y como “Objeto 2” cualquiera de los de tipo lista de la tabla asociada. En este caso “Tareas”

2.- No mostrar en la vista de datos ningún registro de una tabla al entrar en el formulario que hace de menú.

Mi opción preferida… sólo mostramos registros cuando el usuario los seleccione.

En este caso, el proceso no vamos a necesitar igualmente… en el flujo, el “Objeto 2” de la vista de datos tiene que saber que mostrar. La única diferencia es que el proceso asociado no tendrá ninguna línea.

Vista de datos, sin datos

 

Parece increible pero si,  en velneo tenemos procesos que no hacen absolutamente nada… por lo menos aparentemente.

De esta forma, al entrar en el menú no aparecerá ningún registros y será al pulsar sobre un botón cuando se lance la búsqueda que devolverá los registros a la vista de datos.

Tienes el ejemplo completo aquí.

3.- Mostrar en un subformulario de una ficha, un plural (sin optimizar)

En esta caso, ya vamos a estar situados en una ficha, por lo tanto tenemos que tener cuidado con el flujo a la hora de crear los objetos asociados a la vista de datos.

Vista de datos con origen ficha

El montaje es similar a los casos anteriores.

Si recordáis, en uno de los consejos que hemos visto antes os decía que Velneo carga todos los objetos al entrar en este formulario. Por lo tanto los registros que existan en el plural “Desglose de horas” también se cargarán al entrar en la ficha… si tuviésemos 10 plurales mas (sin optimizar) también se cargarían y dependiendo del número de registros que tengamos en cada uno de ellos, es probable que la visualización de la ficha en cuestión se retarde… Y puede además que el usuario sólo quiera ver las “Horas presupuestadas”.

En este caso, lo más sencillo es esto:

Vista de datos de un plural sin optimizar

 

Lo primero es declarar el flujo del proceso, es decir de un origen ficha (de la tabla en la que nos encontremos) queremos mostrar una lista de la tabla destino.

La instrucción para conseguir esto en el proceso es:

  • Cargar el plural que nos interese de la ficha
  • Añadir lista a la salida (invertir lista es para que aparezcan los registros mas recientes al principio de la lista).

Este proceso será el “Objeto 1” de nuestra vista de datos y como “Objeto 2” podremos seleccionar cualquiera de tipo lista del plural en cuestión.

4.- Mostrar en un subformulario de una ficha, un plural (optimizado)

Vamos a realizar algún pequeño cambio para que este montaje esté optimizado y solamente se carguen los plurales al entrar en la pestaña en cuestión.

Vista de datos plural sin datos

 

El flujo del proceso será el mismo… sólo que no le incluiremos ninguna instrucción. De esta forma al entrar en la ficha no se cargará el plural correspondiente.

Ahora tendremos que conseguir que al entrar en la pestaña del plural se carguen en la vista de datos los registros existentes.

Para ello crearemos un “Manejador de evento” en el formulario con las siguientes instrucciones:

Manejador vista de datos

Crearemos una cesta local de la tabla plural que hará de “puente” entre los registros que devuelva el plural y nuestra vista de datos (los registros encontrados se guardarán en dicha cesta).

Con la instrucción “Interfaz: Procesar” accederemos a nuestra vista de datos añadiéndole los registros devueltos por el plural y guardados temporalmente en nuestra cesta con la instrucción “Cesta: Agregar a la lista en curso”.

Sólo nos faltará crear una “Conexión de evento” en el formulario con la señal “On-show” y disparar el manejador que acabamos de crear.

Con este montaje sólo se cargaran los datos de los distintos plurales al acceder a cada una de las pestañas.

 

Espero que a partir de ahora el control vista de datos ya no tenga ningún secreto para ti.

En un próximo artículo veremos todas las instrucciones de proceso que podemos utilizar con este control.

 

¿Alguna duda con respecto al control vista de datos? Si es así, déjame tu pregunta mas abajo en los comentarios.

La entrada Vista de datos: el poder de Velneo al alcance de tus listas aparece primero en AyudaVelneo.

Creación de un menú arbolado paso a paso

Cuando nos acercamos a probar una nueva plataforma de desarrollo, lo primero que queremos es ejecutar algún ejemplo para “ver” como quedaría nuestra aplicación en ese nuevo entorno.

A los desarrolladores que se acercan a Velneo les ocurre lo mismo. Para ello cuentan con el menú arbolado.

menú arbolado

Este planteamiento tiene un problema: quieren “copiar” su aplicación en la nueva plataforma. Idéntica. Mismos menús con las típicas opciones de:

  • Alta de registros
  • Editar registros
  • Eliminar registros
  • Buscar registros
  • Imprimir informes

Os estaréis preguntando el porqué de esta reflexión.

Todo lo anterior viene por este post del foro en el que Carlos dice:

Quiero hacer una app que tiene a la izquierda un dock con opciones arboladas (treeview) al pulsar una rama se contrae o despliega, y al pulsar una hoja ejecuta una acción que abre un formulario. Esta es la base de cualquier sistema pero no me sale. O lo que lei no es -life is soft-. Ejemplo que en access me llevaría 1 hora (ya se que lo domino).

Velneo tiene sus peculiaridades y es verdad que al principio, sobre todo si no has cambiado el “chip”, puede que no descubras todo su potencial… y te des por vencido.

Ya he hablado de ello en “17 errores que te impiden arrancar con Velneo V7“.

En los cursos que he realizado, siempre digo que en Velneo hay que comenzar por el final, es decir por el resultado que queremos obtener:

  • Si quiero lanzar un localizador, primero tendré que tener creada la rejilla a incrustar en dicho localizador y antes el formulario a mostrar al seleccionar un registro. Después crearé el localizador y por último la acción a disparar.
  • Si quiero mostrar un registro desde una búsqueda, primero tendré que crear el formulario de edición de la ficha, después crearé la rejilla (a la que asociaré el formulario creado anteriormente) y por último la búsqueda y la acción.

Pues con las opciones de los menús pasa exactamente lo mismo.

Pasos previos a la creación del menú arbolado

En Velneo lo mas “natural” es tener una única opción de menú para realizar todo el mantenimiento de un módulo… Ya se lo que estaréis pensando “¡sacrílego como es eso posible!”: con el uso de un formulario que “actúa” como menú al que dotamos de toda la funcionalidad que el usuario va a necesitar.

Si no te lo crees te invito a leer antes de continuar “Destripando un formulario menú de vErp” o “Sincronizar vistas de datos en un formulario sin origen“.

¿Ya los has leído?… Pues continuemos.

Con este montaje en el que sólo utilizamos un formulario, logramos simplificar nuestro menú arbolado.

Siguiendo la lógica que te acabo de explicar, el siguiente paso será crear las distintas acciones que vamos a disparar desde nuestro menú.

Montando nuestro menú arbolado

Una vez que hemos montado nuestro formulario que actuará de menú, ha llegado la hora de crear los objetos necesarios para lanzarlo desde el menú arbolado.

Vamos a suponer que queremos montar algo como lo de la siguiente imagen:

Opciones del menú arbolado

Tendremos que crear un árbol de opciones con:

  • Maestros
    • Opciones del menú maestros
  • Oportunidades
    • Tareas
    • Oportunidades
    • Resumen de oportunidades
  • Control de horas
    • Opciones del menú control de horas

Vamos a crear los objetos necesarios para el menú de oportunidades.

Creando las acciones

Necesitamos 3 acciones:

  • TAR_CRM_MEN: lanzará el menú de tareas
  • OPO_CRM_MEN: lanzará el menú de oportunidades
  • RES_OPO_CRM_MEN: lanzará el menú de resumen de oportunidades.

Cada una de las acciones debe quedar como esta de la imagen:

 

Acción oportunidades

Lo importante de la acción son las siguientes propiedades:

  • Comando: en este caso “Disparar objetos”.
  • Objeto 1: objeto a disparar. En este caso el formulario OPO_CRM_MEN que es el que hemos visto en la imagen anterior.

La estructura de las demás acciones será la misma que esta, cambiando las propiedades por los otros módulos a crear.

Por ejemplo la acción de “Tareas” quedaría así:

Acción tareas

Una vez definidas todas las acciones, ha llegado el momento de crear los menús.

Creando los menús

Vamos a crear 4 objetos menú para montar nuestro árbol:

  • MEN_MAE_CRM: para mostrar las opciones de maestros.
  • MEN_OPO_CRM: para mostrar las opciones de oportunidades. En este caso, incluiremos las siguientes acciones:
    • TAR_CRM_MEN
    • OPO_CRM_MEN
    • RES_OPO_CRM_MEN
  • MEN_RES_CRM: para mostrar las opciones de resumen de horas.
  • MEN_GEN: menú que incluirá, en lugar de acciones, los tres menús anteriores.

El menú de oportunidades, quedará como el de la imagen inferior:

Menú oportunidades

Ya tenemos casi construido nuestro “lego”. Nos falta poder visualizar nuestro menú de opciones.

Visualizando el menú arbolado

Como diría un amigo mío, “ya está todo prácticamente a medias”. Tenemos los objetos creados pero todavía no podemos visualizar nuestro menú arbolado.

Para poder hacerlo, vamos a crear un formulario… ¡siiiiiii! vamos a  visualizar nuestro menú arbolado dentro de un formulario.

Menú general vCrm

Si os fijáis en el formulario, la propiedad “Tabla asociada” está vacía… es un formulario sin origen.

Dentro del formulario hemos creado un control de tipo “Menú arbolado” cuyas propiedades son:

Propiedades menú arboladoi

En la propiedad “Estilo“, le indicamos que sólo queremos una rama abierta y que con el simple click, dispara la acción.

En la propiedad “Objeto“, le indicamos el menú que queremos mostrar… en este caso “MEN_GEN”, que es el que incluía los otros tres menús de opciones.

Ya estamos terminando nuestro montaje. Sólo nos falta decidir desde donde vamos a lanzar nuestro formulario “Menú arbolado”.

Modificando el marco “Autoexec”

Para ello, en nuestro marco “Autoexec”, vamos a crear un nuevo subobjeto, en este caso un “Dock”:

Dock menú arbolado

  • En la propiedad “Objeto“, le indicamos el objeto a incluir. En este caso nuestro formulario “MEN_GEN”.
  • En la propiedad “Posición” le indicamos dónde queremos mostrarlo. En este caso a la izquierda.

Y ahora si… por fin podemos ejecutar nuestra aplicación y nos aparecerá un maravilloso menú arbolado a la izquierda de la misma.

¿Has comenzado a cambiar ya el “chip” Déjame tu opinión mas abajo en los comentarios.

La entrada Creación de un menú arbolado paso a paso 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.