may 24

Cambia el chip

Que puedo decir, acabo de enterarme por el blog oficial de Velneo, y parece que se refieren a mi, mejor deberiais leer el post original antes de continuar…

Leer la noticia completa…

Espero que ahora podais entender porque he tenido un poco abandonado el blog, como podeis ver, no he dejado de escribir, todo lo contrario, he escrito aún más y con más ilusión.

Han sido varios meses de duro trabajo en el que he gastado la tinta de cientos de boligrafos y una cantidad indecente de oleo para dibujar las imágenes. :)

Espero que el resultado sea del agrado de la mayoría, y sobre todo, que este manuscrito cumpla su objetivo principal, que es:

¡¡¡ Cambiar el chip !!! y ayudar a entender la filosofia de Velneo V7 como herramienta que consigue que algo tan abstracto como puede llegar a ser la programación, sea divertido y ameno.

Espero que reserveis con tiempo vuestro ejemplar, para que así me de tiempo a realizar las copias necesarias para cada uno de los interesados. Además necesitare realizar un pedido de plumas,  oleos y papiros que determinaré en función de los pedidos realizados.

Nos vemos en el evento, 😉

¡LIFE IS SOFT!

PDF Printer    Enviar artculo en formato PDF   
comments: 15 »
jun 24

Calentito, calentito

Esta semana ha sido intensa en emociones, buenas y malas, y os lo voy a contar, para que podais preveer los problemas que me han surgido y que me han dado tantos quebraderos de cabeza en tan poco tiempo.

Todo viene, a cuento de que hay que cambiar los tipos de IVA, de lo que se deduce que al final, el culpable es el gobierno, como de casi todo lo que pasa es este pais.

Pero no nos desviemos del tema, habia que cambiar los tipos de IVA y he realizado los cambios necesarios en el mapa (en V6.x) para preveer todos los posibles problemas que puedan surgir ese dia, ya que debe estar funcionando paralelamente con los 2 tipos de IVA, y permitir realizar ventas en julio al 18% y facturar albaranes de junio al 16% entre otras cosas, modificaciones que no estaban previstas en el mapa.

Total, que se hicieron las modificaciones, y vamos a realizar las pruebas oportunas para comprobar que el dia 1 de julio todo sera correcto, asi pues:

  1. detenemos en el servidor de V6 una de las empresas,
  2. hacemos una copia de seguridad de la carpeta completa para poder usarla como empresa de pruebas,
  3. se publica la nueva empresa en el servidor,
  4. se asignan los permisos a los usuarios,
  5. se instala la nueva versión del mapa modificado para la ocasión,
  6. se reinicia la aplicacioón y ya esta todo listo para probar.

Todo en marcha de nuevo, comienzan las pruebas, se hacen albaranes, pedidos, presupuestos, se prueban todos los procesos implicados en documentos que usan los diferentes tipos de IVA y se procesan los albaranes para ser facturados y contabilizados, y ¡voila!, que alegria :D, porque salvo por un pequeño despiste en presupuestos, todos los demas documentos y procesos funcionaban estupendamente.

Que alegria, despues de unos meses complicados por cambios estructurales imprescindibles, de regeneracion de una parte esencial de la aplicacion que habia desaparecido, y de migraciones en datos que debian ser realizadas “SI o SI”, las cosas parece que empiezan a funcionar y todos estamos alegres y felices.

Lo malo que tienen estas cosas, es que la sensación de euforia suele durar poco, porque a partir de ahi empiezan a surgir otros problemas que nada tenian que ver con los cambios realizados en el mapa,

* desde la ficha del cliente, ¡no puedo entrar en la ficha contable del cliente!
* desde el menu principal, ¡los ficheros de TLR se importan mal, no aparecen los datos del cliente!
* y otros problemas que nada tienen que ver con el IVA, y ademas, en la empresa original, ni siquiera en la copia, teniendo en cuenta que el mapa de la empresa original no habia sido modificado.

Tras varias horas interminables de ayer, y un par de horas mas hoy que solo podia pensar en “Tierra !tragame!”, como una luz me vino a visitar, y parece que el proplema ya esta solucionado.

La causa del problema, precisamente la copia de seguridad, y es que el mapa usado en la empresa hace uso de un fichero VRT, que contiene datos comunes a varias empresas y que por tanto, tambien estaba siendo usado por la nueva empresa de pruebas.

Este problema no hubiera existido de no haber sido por estas pruebas, o quiza hubiera sido mucho peor mas adelante, por otras causas.

El problema en si, “Que habian dos mapas en ejecución, en diferentes empresas, con cambios en la estructura de tablas, abriendo algunos ficheros comunes”

La solución, sencilla, se ha parado el servidor, se ha copiado la carpeta comunes, se ha redireccionado el fichero VRT a la copia de la nueva carpeta y se han separado fisicamente los datos de la empresa original y la de pruebas, y ahora si, ahora todo funciona correctamente y ha vuelto la normalidad.

Y menos mal que teniamos copia el mapa anterior a las modificaciones, porque recuerdo que no es posible restaurar la copia de seguridad si no se dispone de una copia del mismo mapa que hay instalado en la propia copia, en el fichero “VCS”

Pero ¡que susto!, ahora un cafetito y me voy de vacaciones, que me las he ganado, al menos, eso creo.

Y ha salido el sol, al final va a ser un buen dia :)

aunque, siempre habra alquien que intente joderlo … ¿o no?

PDF Download    Enviar artculo en formato PDF   
comments: Comentarios desactivados en Calentito, calentito
jun 11

Reinstanciar una aplicación

Posted in analisis, vAdmin, vServer

Nuevamente aqui para realizar otra sugerencia / critica al actual sistema de instanciacion de vAdmin, pero antes de eso un poquito de historia:

En V6, instalar una actualización de una aplicación, es tan sencilo como Pegar el Archivo.VAM en el servidor, en la carpeta correspondiente donde tambien estan los datos, excepto que se hayan redireccionado con un VRT. ycon el boton derecho del raton, elegir la opcion de Reiniciar la aplicacion, y esta se reinicia automaticamente o queda en espera hasta que todos los usuarios abandonen su conexion actual

En V7, esto tiene algo mas de lio, porque en condiciones normales es muy similar, pegamos los proyectos de la solucion en la carpeta del servidor (a no ser que ya estemos trabajando con vServer en edición y ejecución al mismo tiempo) y reiniciamos las instancias de aplicación y las instancias de datos, y es aqui donde empieza a liarse la historia, ¿porque?:

  1. Porque cuando se instancia una aplicación (una solución con varios proyectos), normalemente se instancia el proyecto principal (el que hereda a todos los demas) y se acepta casi siempre la misma carpeta para todos los proyectos de datos, juntando en una misma carpeta, todos los archivos de datos de todos los proyectos.
  2. Se podrian instanciar los proyectos por separado, pero la primera opción es la mas rápida y la mas habitual, y serán muy pocos los casos en los que realmente sea necesario compartir estos datos, al menos, de momento.
  3. Cada vez que se modifica una aplicación de forma externa al vServer y pegamos las modificaciones, necesitamos reiniciar ¿que?, porque yo tengo un lio de narices, no se si reiniciar el proyecto principal de aplicaciones que hereda a los demas (no estoy seguro de que esto reinicie todos los proyectos), tambien tengo que reiniciar el proyecto principal de datos (y me pasa lo mismo con los proyectos heredados). En fin, que para evitar tanto lio, lo mas rapido y seguro es, ir al panel de control y Reiniciar el servicio directamente, asi, con 2 pelotas. Quiza en la versión 7.4 esto ya esta solucionado con la opcion de probar las modificaciones
  4. Siguiente problema y muy importante, ¿que pasa si creo un proyecto nuevo y lo interpongo entre otros proyectos ya existentes por medio de la herencia?, pues pasa que vAdmin me da un error y no puedo ejecutar el proyecto con vClient hasta que lo solucionas. Pero ¿cual es la solución?, porque si instancio este nuevo proyecto, me vuelve a instanciar todos los proyectos heredados nuevamente y los repite, quizá funcione bien, pero se empiezan a acumular lineas en vAdmin y encontrar el proyecto que necesitamos reiniciar, puede llegar a ser un puzzle. Quiza la mejor solucion actualmente es , hacer copia de seguridad de los datos (por lo que pudiera pasar) anular todo y reinstanciar de nuevo toda la aplicacion para evitar duplicidades, pero esto lo hago ahora que son pruebas, en un cliente, ni de coña.
  5. ¡Joder!, me ha llamado la mujer para comprar un pollo asado para comer, y se me olvido lo que iba a seguir, asi que, cuando lo recuerde, continuaré… 😉

He aqui yo conmigo mismo y mis problemas, hablando al viento sin saber quien me escucha, y gracias, a los que al menos, aguantais estas paridas.

Pues eso, que el vAdmin tambien necesita una buena revisión …

Create PDF    Enviar artculo en formato PDF   
comments: 9 »
mar 15

Seguridad en los datos

Posted in v7, vServer

Tras las pruebas realizadas con la importación de datos en las tablas de contabilidad Asientos y Apuntes, las primeras impresiones fueron bastante buenas, los tiempos de acceso y los tiempos empleados en las operaciones resultaron muy aceptables teniendo en cuenta las condiciones en las que se realizarón dichas tareas.

No obstante, y debido a la falta de tiempo, lo que obliga a realizar las pruebas a altas horas de la noche, y tras largas jornadas de trabajo, suelen surgir problemas que posiblemente sean culpa del cansancio que a ciertas horas no podemos evitar. El caso es, que por no se que motivo, se han producido varias situaciones que se deberian tener en cuenta para evitar la consecuencia final, que se deriva en perdida total de datos en la tabla de Asientos.

Voy a exponer los 2 problemas mas frecuentes que me han surgido:

1. vClient se cuelga (o quiza no este colgado) pero cuando se solicita una accion, y vClient no responde tras 10 o 15 minutos de espera, uno cree que esta colgado y ejecuta el administrador de tareas para interrumpir la operación.

2. vClient esta en ejecución y como uno anda como loco, con vClient, vDevelop, vAdmin, en ocasiones minimizados en la barra de tareas de Windows, pues para ahorrar tiempo, y no tener que estar reiniciando instancias una por una, se me ocurre que es mas fácil, Detener el servicio de vServer desde el Panel de Control y volver a iniciarlo despues. De esta forma, me aseguro que todas las instancias estan correctamente actualizadas y disponibles. Pero luego me doy cuenta de que vClient, permanece abierto y estaba conectado al servidor, asi que lo cierro y vuelvo a entrar, pero no se que problemas puede haber causado el dejarlo abierto.

En el primero de los casos, no se puede evitar, si se ha colgado, pues que le vamos a hacer. Pero en el segundo de los casos, creo (y no se si será posible) que vServer te avise de que hay enganches activos antes de ser Detenido, porque luego pasa lo que pasa.

Y no es moco de pavo, el resultado de esto, es que teniendo datos en los ficheros (comprobado directamente sobre la carpeta de la instancia de datos) los datos han desaparecido y no soy capaz de visualizarlos.

Solución: no me queda otra que Regenerar area de datos y Regenerar indices, pero tras la operación, ocurren dos cosas muy distintas, si tenemos en cuenta que se habian perdido los datos de las tablas Asientos y Apuntes, pero no los datos de las tablas maestras

1. Al regenerar datos e indices de Apuntes, aparecen todos los registros y aparentemente se soluciona el problema en esta tabla, OK.

2. Al regenerar datos e indices de Asientos, los datos del fichero desaparecen y el fichero queda fisicamente vacio. Antes de regenerar el fichero tiene un tamaño de mas de 2 Mb. y despues de regenerar tiene un tamaño de 2 Kb. es decir, la estructura de la tabla vacia.

No se como, y no se exactamente porque se ha producido el fallo, posiblemente por estar los registros bloqueados por el servidor, durante cualquiera de los inconvenientes que he detallado.

En cualquier caso, el problema es lo suficientemente importante como para ser revisado y solucionado a la mayor brevedad, ya que en una instalación real, éste problema hubiera ocasionado una seria discusión con el cliente final.

Salvo por este problema, todas las pruebas realizadas han sido muy satisfactorias.

PDF Printer    Enviar artculo en formato PDF   
comments: Comentarios desactivados en Seguridad en los datos
mar 11

Importacion de datos contables – 2ª parte

Posted in v7, velneo, vServer

Seguimos con las pruebas de importacion de datos esta vez si, ya he terminado las pruebas inciales que permitiran trabajar con datos reales y ver el comportamiento de la aplicacion en situaciones reales.

Porque hasta ahora solo habia podido hacer pequeñas simulaciones, para realizar estas comprobaciones, decir que se han manejado los datos obtenidos de la importacion publicada ayer.

Es decir:
Los datos se obtienen de una tabla de datos del mismo proyecto en el que vamos a crear los asientos y apuntes correspondientes, y por tanto en esta ocasion si que hay una pequeña variacion con respecto a las pruebas anteriores:

  • El proceso que realiza todas las operaciones se ejecuta en 3 plano en el servidor
  • El equipo utilizado para el trabajo ha sido el mismo HP 4510s
  • El numero de asientos creados es de 12,068
  • El numero de apuntes creados es de 39,281

El tiempo empleado en realizar esta operacion es de 1 hora y 2 minutos, quiza demasiado tiempo, ¿o no?

Para la generacion de asientos y apuntes se han usado las siguientes tablas:
Tabla de asientos: Longitud de 205 bytes, 55 campos , 19 indices
Tabla de apuntes: Longitud de 198 bytes, 44 campos , 19 indices

Vamos a ver que es lo que hizo el proceso y cuales fueron los tiempos medios empleados
en realizar dichas operaciones:

Esto se repite exactamente 12,068 veces

  • Lectura de la linea de origen en una tabla
  • Parsear 5 campos de la cabecera con StringSection
  • Grabar la ficha del asiento en otra tabla
  • No realiza actualziaciones de ningun tipo

Esto se repite exactamente 39,241 veces

  • Lectura de la linea de origen en una tabla
  • Parsear 8 campos de la linea con StringSection
  • Grabar la ficha del apunte en otra tabla
  • Realizar las 3 actualizaciones por cada apunte a la cabecera

El resultado de las tablas de asientos y apuntes es,
Tamaños de los archivos de datos Asientos: 2,37 mb y Apuntes 7,42 mb
Tramaños de los ficheros de indices: Asientos 3,88 mb y Apuntes 12,2 mb

Esto significa que el tiempo empleado en grabar cada apunte y actualizar a la cabecera : 0,0316   es decir, 31,6 registros por segundo

Tras finalizar el proceso y realizar los calculos correspondientes para preparar este artículo, comencé a comprobar el resultado obtenido a traves de las tablas y la mala noticia es que habia un asiento descuadrado, pero no tiene importancia, la buena noticia es, que dicho asiento ya estaba descuadrado antes de ser exportado.

Por tanto, el resultado, todo correcto, parece que esta vez si, se ha solucionado el problema existente en los calculos numericos con decimales.

A raiz de estos datos, que cada uno saque sus propias conclusiones …

PDF    Enviar artculo en formato PDF   
comments: Comentarios desactivados en Importacion de datos contables – 2ª parte
mar 10

Importación de una contabilidad completa – 1ª parte

Posted in v7, velneo, vServer

Para realizar las pruebas actuales he utilizado el mismo equipo del articulo anterior y he separado las pruebas en dos partes.

La primera parte realizada ayer, fue la exportación de datos de una aplicación realizada en V6 que generaba un fichero de texto en LML con una contabilidad completa, y un total de mas de 70,000 lineas

El tiempo empleado en generar el fichero no es importante, ya que lo que se esta evaluando es V7 y no V6. El fichero generado tiene un peso de 5,19 mb en total

Tras realizar la exportación de datos, se inicia el proceso de lectura e importación del fichero LML.

Tras seleccionar el fichero y teniendo en cuenta que el proceso de importacion se ejecuta en primer plano y el servidor esta en Local como en las pruebas anteriores, el proceso se inicia y finaliza 9′ 35″ minutos despues un tiempo un poco mas elevado que la lectura de los procesos anteriores, pero que compensa al realizar los calculos de tiempos de procesado,

  • El fichero LML inicial tiene un peso de 5,19 Mb
  • El numero total de lineas procesadas del archivo LML es de 71,712
  • El tiempo de lectura y parseo total del fichero es de 9′ 35″
  • El tamaño resultante total del archivo.DAT es de 18,8 Mb
  • El tamaño resultante total del archivo.IDX es de

En cada lectura del fichero se procesa una linea de texto (mas de 70,000 lineas) en cada linea leida, se procesa con StringSection 3 veces (mas de 210,000 sentencias) al finalizar, se guarda un registro en la tabla correspondiente con 340 bytes por registro y 4 indices (mas de 71,000 registros guardados)

El resultado obtenido es de un tiempo de 0,0080 segundos en cada una de las lineas leidas y procesadas.

Mañana continuaré con el resultado final de estas pruebas…

Es decir la generación de asientos y apuntes en sus tablas correspondientes.

PDF    Enviar artculo en formato PDF   
comments: 1 »