06 Oct Algunos conceptos que debemos tener claros sobre Velneo V7.

Presentamos esta nueva sección de «Velneo a fondo» con 2 objetivos principales:

• Explicar en detalle los comandos y características de la plataforma de desarrollo Velneo.
• Mostrar trucos y ejercicios prácticos que hagan más divertido programar con Velneo.

Los artículos de esta sección serán una fuente de información de aquellos aspectos de Velneo que no encontramos en el manual de ayuda.

Cogeremos un comando o funcionalidad de Velneo y explicaremos a fondo sus características más útiles e interesantes para el programador.

También habrá como no, trucos que hagan más sencillo y divertido programar con Velneo. Finalmente diseñaremos pequeñas aplicaciones, planteadas como ejercicios prácticos que pongan a prueba nuestros conocimientos.

No pretendemos enseñar a programar, sino conocer a fondo Velneo de tal forma que facilite el desarrollo de nuestras aplicaciones.

Queremos que los artículos sean útiles tanto a los programadores que empiezan a conocer la herramienta como a los que ya llevan tiempo con ella.

Antes de meternos en materia y como primer artículo de Velneo a fondo vamos a enumerar una serie de conceptos que consideramos interesantes tener claros. Es una lista que irá creciendo en próximas entregas y conviene revisarla periódicamente para comprobar que tenemos claros los conceptos básicos de Velneo.

Conceptos básicos sobre Velneo V7

vDevelop

Con vDevelop estamos editando los proyectos de Aplicación (código fuente) y los proyectos de datos (estructura de las tablas). En ningún caso con vDevelop generamos contenido en las tablas (las tablas estáticas no cuentan).

En vDevelop, cada vez que pulsamos F5, se producen las mismas acciones que realiza el VIN en Producción, se reinicia la Solución en desarrollo con los cambios realizados (código fuente y estructura de tablas).

En alguna ocasión necesitamos cambiar el identificativo de un campo, pero esto produce la pérdida de los datos ya existentes en ese campo.

El subobjeto Traspaso de campo facilita la migración de información entre campos de una Tabla y el control de versiones. De esta forma ya podremos cambiar el identificativo de los campos y traspasar los datos antes de eliminar el campo original.

Lo que se llama migración masiva de datos no tiene nada que ver con los ficheros .VIN, éstos actualizan la estructura de tablas y las migraciones habrá que programarlas con código fuente en la aplicación.

Los nombres de las Tablas nunca deben cambiarse o habrá problemas en la actualización.

En el editor de informes nativos las reglas están en pulgadas y los valores de las propiedades se deben poner en pixeles:
100px = 1pulgada = 2,54cm.

Esto vale para los tamaños de los controles, pero para los márgenes se sigue otra equivalencia:
Márgenes -> 50px = 1pulgada = 2,54cm

Aunque la calidad del renderizado en pantalla de los Informes nativos es deficiente, el comando de proceso “Imprimir Informe” y generar PDF mejoran considerablemente la calidad de impresión.

Usar siempre Aspecto de dibujo = Proporcionar para que los dibujos salgan al tamaño deseado.

Los objetos por sí mismos no muestran Listas de registros, necesitan que en el flujo de ejecución el objeto anterior haya creado una Lista (o Ficha) de la misma Tabla asociada al objeto destino.

Las Vistas de Datos permiten concentrar varios objetos en un flujo para que el resultado sea la Lista (o Ficha) mostrada en el control visual  (rejilla, formulario, casillero, …).

El comando de instrucción Recalcular (Vista de datos) vuelve a Disparar los objetos que integran el control Vista de datos para obtener de nuevo la Lista. Es decir, se vuelven a comprobar todos los parámetros que conforman la Vista de Datos.

Desde un Manejador de Evento de un Formulario no tenemos Acceso a los Manejadores de Evento de los subobjetos de dicho formulario.

Los procesos siempre ejecutan los formularios en Modal (Ventana de Diálogo). Para mostrar el formulario No Modal necesitaremos ejecutar una Acción que establezca un flujo nuevo.

Todos los objetos de las Bases de datos (Triggers, Actualizaciones,…) se ejecutan siempre en el servidor.

Los planos de ejecución son absolutos: 1º plano en cliente, 2º plano en cliente multitarea y 3º plano en servidor.

El plano donde realmente se ejecutará el objeto dependerá del plano absoluto en el que se encuentre el objeto llamador.

Así un proceso en 3º plano ejecutará todos los objetos subsiguientes en el servidor, independientemente del valor del parámetro Plano de ejecución.

Los objetos (incluso los procesos) no pueden dispararse (Disparar Objeto) en 2º plano, porque necesitan de un handle local al proceso llamador.

Las Listas (y las Fichas) únicamente guardan un puntero interno al registro físico de la Tabla en el vServer.

Los registros físicos de las tablas llevan asociado un número de registro o puntero interno (no es el ID) que sirve como puntero para las Listas y Cestas. Tiene un tamaño de 4 Bytes (4.294.967.295). Es el número que aparece a la izquierda en las rejillas.

Las Cestas son Listas de punteros a registros de una tabla. No almacenan información, solo apuntan a los registros.

La Caché de fichas acelera la carga de los datos en Local. Cuando establecemos una transacción de lectura/escritura se fuerza siempre la lectura de la ficha desde el Servidor para tener siempre la última versión.

Lo que viaja entre cliente y servidor son listas de punteros, no fichas completas de campos. La ficha completa se cargará solo cuando vClient necesita acceder a un campo de la ficha.

El Bloqueo Blando es el que realizan los formularios por defecto. El Bloqueo Duro es el que realizan los Procesos que transaccionan y los formularios con Estilo = Bloqueo Duro.

En Bloqueo Blando las transacciones son independientes para cada tabla. En Bloqueo Duro la transacción es global a todo el Proceso o Formulario.

El Refresco terciario no se produce en formularios Modales.

Las Funciones en 1º Plano siempre generan transacción independiente, aunque ya estén dentro de otra transacción. En 3º Plano las Funciones se integran en la transacción abierta.

Las Variables Globales en disco se comparten por el Cliente y el Servidor. Usarlas para leer datos globales una vez, almacenando su valor en una variable global en memoria.

Las Variables Globales en memoria no se comparten entre el Cliente y el Servidor.

Las Tablas en memoria pueden usarse para dar de Alta registros de manera diferida en 2º plano.

Las Tablas en memoria no se comparten entre Cliente y Servidor.

vServer

vServer de forma nativa tiene los mecanismos necesarios para actualizar una Aplicación en Producción de forma segura y fiable, no necesitamos herramientas externas.

Para actualizar una aplicación podemos prescindir del fichero .VIN y como alternativa, simplemente copiamos los ficheros de los proyectos de aplicación (vca) y de datos (vcd). Una vez copiados es suficiente con reiniciar la Solución.

Una determinada Solución solo puede ser reiniciada si no existe ninguna instancia en ejecución en otras Soluciones que la hereden.

Cada Instancia de datos apunta a una carpeta donde se guardan las Tablas de la Aplicación. Estas tablas son ficheros del sistema de archivos y pueden manipularse como tales.

Por ejemplo: cuando queremos sustituir la tabla auxiliar de Códigos postales por una nueva, simplemente paramos la Instancia de Datos y sustituimos los ficheros de dicha tabla (dat e idx). Por supuesto lo podemos hacer remotamente por FTP, SDV…

vInstallBuilder

Una vez terminado el trabajo con vDevelop y probada la aplicación en desarrollo, se genera un fichero .VIN con vInstallBuilder. El fichero .VIN se compone únicamente de los proyectos de Aplicación y Datos, es decir, código fuente y estructura de las tablas.

Existe la opción, si es necesario, de añadir al VIN algunas tablas para que la Aplicación disponga de ellas. Por ejemplo: queremos incorporar a nuestra aplicación las tablas de Códigos Postales y Poblaciones.
Normalmente el VIN irá sin tablas (lo que se conoce como VIN vacío), pero siempre irá con el código fuente y la estructura de las tablas (o sea la Solución).

El fichero .VIN es el que llevamos a Producción (Cliente). El fichero .VIN actualizará los proyectos de Aplicación y Datos del vServer.

Ahora viene lo más importante: cuando se reinicia la Solución, las instancias de Aplicación ejecutarán el nuevo código fuente y las instancias de Datos actualizarán la estructura de las tablas a partir de la nueva estructura del proyecto de Datos.
Las tablas que ya existen verán actualizada su estructura y las que no existen se crearán vacías, pero NUNCA SE SOBRESCRIBEN DATOS.
Entonces no tiene sentido incorporar tablas al VIN, excepto cuando queremos instalar una Aplicación con datos de prueba o incorporar nuevas tablas auxiliares.

vClient

En sistemas Windows, analizando el Setup de vClient y el registro, observamos que Velneo no instala absolutamente nada, simplemente copia la carpeta Velneo/V7 con las librerías de QT, librerías C++, el vUpdater y el ejecutable vClient.exe.

Los paquetes de distribución de Runtimes C++ realmente sobran del Setup ya que pueden ser descargados de Microsoft e instalarse una sola vez por separado (ver https://support.microsoft.com/es-es/kb/2977003).

El cliente vUpdater no es necesario, si vClient no lo encuentra simplemente lo ignora y ejecuta la versión vClient disponible.

El uninstall-vclient.exe simplemente lo que hace es borrar la carpeta Velneo/V7. Se puede ejecutar en modo silencioso con /S.

Así que el despliegue de vClient puede consistir en empaquetar la carpeta de Velneo/V7 en un zip con los ficheros necesarios, copiarla a la máquina del cliente y descomprimirla en la carpeta que queramos.

Con esto podemos tener varias versiones de vClient ejecutando de forma simultánea.

Optimización

El campo Alfa 256 es el más rápido de gestionar de los campos alfanuméricos. No confundir con el tamaño del campo.

Índices. No abusar innecesariamente de ellos. Lleva su tiempo gestionarlos.

Los Índices Condicionados, aunque penalizan un poco, merecen la pena cuando se transacciona poco y se lee mucho.

Las Rejillas con campos de tipo objeto demoran la carga para evitar lapsus en la visualización de los registros.

¿Cuántos de estos «conceptos básicos sobre Velneo V7» conocías?. Ya sabes que valoro tus opiniones sobre los artículos… puedes dejarla mas abajo en los comentarios.