mar
15
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.
mar
11
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 …
mar
10
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.
mar
7
Después de una semana bastante cargada de trabajo, que no me ha permitido sacar tiempo ni para publicar, ni para realizar demasiadas pruebas en v7, he podido sacar un poco de tiempo para realizar las primeras importaciones de datos y comprobar asi la versión actual.
Para poder analizar los datos obtenidos hay que tener en cuenta que las pruebas han sido realizadas en un ordenador portatil convencional, nuevo, pero con unas prestaciones normales para cualquier portatil actual.
Especificaciones tecnicas del equipo:
- Portatil HP ProBook 4510s con 4 Gb de RAM y 250 Gb de Disco Duro
- Sistema operativo Windows Vista (preinstalado en el equipo y original)
- Antivirus Panda IS-2010 (legalizado)
En cuanto a las caracteristicas del servidor V7 utilizado para estas pruebas son:
- vServer V7 7.3.0.8651 con instalación en Local
- Archivos de datos (en LML) en disco Local
En cuanto al tamaño de los archivos utilizados para importar la información, ha que decir,
- que se han utilizado 8 archivos diferentes para las pruebas de importación,
- que cada uno de los archivos contiene exactamente 15,000 lineas de texto en LML, excepto el ultimo que contiene 10,000, es decir un total de 115,000 lineas de texto en 8 archivos ASCII en formato LML
- que el tamaño de los archivos, varia en función de la longitud de las lineas, pero que oscilan entre los 704 Kb del archivo mas pequeño (15,000 lineas con una media de 50/60 carácteres por linea) y los 3,04 Mb del más grande (15,000 lineas con una media de 250 carácteres por linea). El último archivo, a pesar de tener solo 10,000 lineas, pesa 1,47 Mb.
Para realizar la importacíon se ha utilizado un proceso sencillo que permite seleccionar el fichero a importar desde la ventana de dialogo correspondiente, y comienza la lectura secuencial del fichero hasta finalizar. El proceso se lanza directamente desde el menu y no se ha utilizado ningun proceso adicional para su ejecución en 3 plano. Por tanto, se ejecuta en 1 plano de inicio a fin.
En el proceso se han utilizado varias sentencias StrinSection para parsear las lineas en LML y se asigna cada valor a su campo correspondiente, la tabla contiene exactamente 4 campos + el #ID automático y 3 índices + el #ID de la tabla. El único campo que no ha sido indexado, es el que contiene el texto de la linea importada del fichero.
Esto significa que el proceso lee 15,000 lineas del archivo, ejecuta 60,000 sentencias StringSection y genera 15,000 registros en una tabla con 4 indices y un tamaño de 340 bytes por registro.
Los resultados obtenidos:
En la lectura de los ficheros mas pequeños (700 Kb), el tiempo aproximado de ejecución del proceso fué de 2:40′ (2 minutos y 40 segundos)
En la lectura de los ficheros mas grandes (3,04 Mb), el tiempo aproximado de ejecución del proceso fué de 2:55′
A pesar de que el fichero mas grande era 4 veces mayor que el fichero mas pequeño, la diferencia de tiempo fue despreciable (vamos, que ni hay que tenerla en cuenta).
Conclusión:
El tiempo empleado en parsear las lineas es practicamente el mismo, independientemente del tamaño de ésta. Y por tanto, la función StringSection va que te cagas 
El tiempo empleado en la lectura de los ficheros tambien es el mismo, asi que, se ha utilizado un tiempo medio de 0,012 segundos en la lectura de cada una de las lineas del fichero, y en ese tiempo está incluido tambien, el tiempo empleado en parsear la linea, y la generación del registro en la tabla correspondiente.
El tamaño final de las tablas de datos en disco es de 38,165 Kb en el Archivo.DAT (datos) y de 21,884 KB en el Archivo.IDX (indices)
Otra conclusión mas que he podido obtener de estas pruebas, aunque esa ya la sabia, que LML es el mejor sistema que he probado hasta ahora para importar y exportar datos. 
Pero como en estas pruebas no he utilizado datos numéricos, seguiré realizando mas pruebas, que permitirán tomar decisiones más importantes
El resto de conclusiones y opiniones os las dejo a vosotros, ¿que os parece?
mar
2
He probado los DOCKS horizontales y verticales para trabajar y son muy comodos y me parece una funcionalidad excelente.
Ayer fue un dia especial, continuando con las pruebas esta vez en una solución con un único proyecto de datos con aproximadamente 100 tablas
El caso es que tenia que eliminar una tabla que no utilizaba pero que estaba enlazada como maestra de otras muchas tablas y pense, Elimino la tabla, y luego le doy al boton para buscar errores y voy eliminando los enlaces a la tabla.
En que mala hora se me ocurriria, ya que cada vez que eliminaba el campo enlazado a la tabla maestra, me rompia vDevelop y “CRASH”
A pesar de que volvi a pegar la tabla maestra borrada, Copy & Paste de otro proyecto vDevelop seguia rompiendo.
Al final consegui eliminar los campos pero para ello tuve que hacer 2 cosas
1. eliminar el contenido inicial antes de borrar el campo
2. cambiar las propiedades del campo para apuntar a otra tabla maestra existente
Luego eliminar indices y por fin eliminar el campo enlazado.
Pero claro, guardando el proyecto cada vez que eliminaba varios campos, porque aun asi, a veces seguia rompiendo.
Como la solucion solo tenia un proyecto, vDevelop se movia con soltura, lo que me hace pensar, que vDevelop hace comprobaciones innecesarias en algunos momentos.
P.E. al mover 2 tablas de un proyecto de datos a otro, vDevelop comprueba enlaces a tablas maestras e historicas y mueve todas ellas al nuevo proyecto, pero en el caso del ejemplo, el proyecto solo tenia 15 tablas y las dos tablas movidas no tenian enlaces con el resto. Y a pesar de eso, tarda 3 minutos en mover solo 2 tablas.
Debo aclarar que la solucion completa es bastante grande. Lo que me hace pensar que realiza comprobaciones en todos los proyectos de la solucion, pero no tiene sentido comprobar todas las soluciones, cuando este proyecto no tiene nada mas que una herencia al proyecto al que quiero mover las tablas que estaba vacio.
“3 minutos en mover solo 2 tablas”
Hice esto porque el finde, ya tuve que romper vDevelop, porque tardaba mas de 1 hora en un proyecto con bastantes tablas y no veia cuando terminaria.
Segui trabajando con los esquemas de tablas, y empece a colorear las tablas dentro del esquema, muy comodo por cierto, arrastrando el raton o con la tecla control, marcaba varias tablas y elegia el color y se coloreaban todas a la vez. Chapeau!! (que bien se me dan los idiomas, jeje)
Despues de terminar el esquema, comprobe que habia algunas tablas que no necesitaba en el esquema y las marque con el raton, todas a la vez, igual que al colorear, y pulse el boton ROJO, para eliminar los elementos del esquema, y a que no sabeis que paso….
…. CRASH!!!
asi que decidi descansar que ya era tarde y no me apetecia seguir.
feb
27
He podido comprobar, como al renombrar una variable en una función, que era utilizada como parametro de entrada de datos, esta se renombra correctamente en los parametros. Esto, en la versión anterior, solo lo hacia correctamente cuando la variable era el primer parametro de la función, pero no lo hacia para el resto de los parametros. Asi que parece estar corregido.
Estoy creando una rejilla con el asistente, y quiero incluir una columna con el NAME de un campo enlazado a una tabla estatica, pero no me lo permite, solo puedo incluir, campo enlazado (#ID). El icono tampoco lo puedo seleccionar.
Creo una accion que carga una lista y retorna una rejilla, y funciona correctamente, en ejecucion (modo SDI), no tengo forma de cerrar la rejilla. Tengo que cerrar vClient por completo para cancelar la rejilla. Sera que tengo que asignar una TOOLBAR obligatoriamente con un boton salir, pero bastaria con una tecla aceleradora para cancelar la rejilla.
Sigo realizando pruebas y estoy preparando un proceso de importación, y me hace algo muy estraño:
En el proceso de importación hay 3 lineas con la sentencia CREAR NUEVA FICHA EN MEMORIA ( hFicha, Tabla) y a pesar de hacer utilizado el mismo identificador “hFicha” en las 3 sentencias, al seleccionar la sentencia ALTA DE FICHA ( hFicha ) me los identifica como 3 identificadores distintos y sera por esto que el proceso no me ha funcionado correctamente, porque llevo realizando pruebas durante casi 3 horas y aun no lo he conseguido.
Al final, he conseguido que el proceso funcione, el problema era mio, habia creado un indice de clave unica en la tabla y me agrada saber que ha funcionado incluso mejor que en las versiones 6.x, ya que si el indice es de clave unica no crea el registro, pero en 6.x el registro se creaba en la tabla de datos, aunque no aparecia en el indice correspondiente.
Lo que si me parece desconcertante, es lo de los manejadores repetidos, incluso con el mismo nombre.
Para evitar confusion, he renombrado los manejadores para que tengan nombres diferentes, y asi saber cual corresponde a cada una de las sentencias anteriores.
Seguimos probando…
feb
26
Hace solo unos dias que se publicó la versión 7.3.0.8651 y decidido probarla a fondo para empezar a tomar decisiones sobre el posible uso en algunos proyectos que tengo pendientes.
Para empezar, he tenido que desinstalar la versión 7.2.1 y proceder a la instalación de la nueva versión 7.3 y como no podia ser de otra manera, tras finalizar el proceso de instalación y comenzar a realizar las primeras pruebas, empiezan los problemas.
No consigo acceder a la nube, vAdmin se cuelga, vClient tambien se cuelga y con vDevelop, solo puedo abrir soluciones en local, pero no en la nube, porque tampoco conecta. Me aseguro de reiniciar el Servidor de la nube por si fuera el problema y todo sigue igual. Pero no solo se cuelga vAmin, vClient y vDevelop, sino que tengo que reiniciar el equipo cada vez que esto sucede, porque ya no responde nada.
Tras un par de horas insufribles, decido partir de cero, desinstalo todo de nuevo, anulo los permisos del Firewall, y vuelvo a instalar todo nuevamente y vuelvo a reconfigurar el Firewall y como por arte de magia, ahora todo parece funcionar correctamente.
Bien, ya en marcha, y todo aparentemente bién, empiezo a probar vDevelop y modificar proyectos y ejecutar con vClient.
vDevelop:
Noto que por el simple hecho de abrir un proyecto y sin realizar cambio alguno, aparece activo el boton de Guardar, imagino que es necesario guardar el proyecto para convertirlo a la nueva versión o será porque habia algun error en el proyecto y ha realizado modificaciones automaticamente.
La solución es grande y tiene bastantes proyectos, y noto como vDevelop se mueve mucho mas lento que su predecesor, imagino que es simplemente porque realiza mas comprobaciones en los datos. Pero es que se hace bastante pesado el simple hecho de cambiar de un objeto a otro, y eso obliga a utilizar mucho mas el raton, para ir directamente al objeto seleccionado sin pasar por el resto de objetos. Es decir, el simple hecho de mostrar las propiedades de un objeto situandonos en el, se ha vuelto mucho mas lento.
Veo también que ya es posible volver a mover objetos de lugar dentro de un proyecto, que en la version 7.2 no era posible, pero si en las anteriores. Por algun motivo, esta funcionalidad fue bloqueada temporalmente.
He movido una tabla de un proyecto a otro y sigo viendo un problema importante: cuando se mueve una tabla a un proyecto heredado, esta muy bien que se muevan todos los enlaces a maestros de esa tabla, para mantener la estructura en el nuevo proyecto, pero lo malo es que tambien se lleva consigo los historicos. El resultado es que si en el proyecto, todas las tablas estan enlazadas, al final, lo unico que conseguimos es poder cambiar las tablas de un proyecto a otro, pero todas o ninguna. y eso es un problema, cuando hemos migrado una aplicación y queremos dividirla en modulos mas pequeños. Simplemente, no es posible.
Otro problema que veo, es que no se pueden mover las tablas en sentido contrario, es decir, las tablas historicas, no pueden ser movidas a un proyecto que hereda al actual. Y otro problema mas, al mover los objetos de un proyecto a otro, se pierde por completo la estructura de carpetas y se queda todo completamente desorganizado. Solo podemos elegir una carpeta que este en la raiz del nuevo proyecto.
En cuanto a la ayuda incorporada en la Galeria de objetos, esta muy bién y son muy aclaratorias para poder elegir los nuevos objetos.
vClient:
Al igual que vDevelop, ha reducido sensiblemente su velocidad, he notado como vClient me daba la sensacion de ser mas rapido e incluso mas estable, ya que aparte de los problemas iniciales de la instalación, no he vuelto a tener mas problemas y hasta ahora parece funcionar bastante bién.
vServer:
de vServer, nada que decir, al igual que en la versión anterior, con instalación en Local, se instala y permanece callado y sin dar un solo ruido, y eso creo que debe ser bueno.
Vamos, que aunque está, parece que no, porque no protesta ni dice nada, solo cumple su misión en silencio. Asi que muy bién.
vAdmin:
Pues más de lo mismo, aún no he tenido problemas y eso como ya he dicho, es bueno. Tanto en conexion al vServer local, como en conexión a vServer en la nube. Todas las instancias anteriores permanecen invariables y no he tenido que tocar nada, todas funcionan correctamente.
Cuando tenga algo mas de tiempo empezaré a realizar importaciones masivas de datos y veremos que tal responde.
Por el momento y a pesar de los problemas comentados anteriormente, las sensaciones de estabilidad han sido buenas, aunque si es cierto, que vDevelop se ha vuelto mucho mas pesado (lento).
feb
20
Asi es, faltan solo unos dias para que se haga publica la nueva versión 7.3 de Velneo v7, y esperamos con impaciencia.
Algunas de las novedades más esperadas en esta nueva release, son las Rejillas/Grids con importantes mejoras, el nuevo objeto TPC, y otras que nos eran muy importantes para los que ya usabamos las versiones 6.x y anteriores.
Otra gran noticia que esperamos todos con impaciencia, es la publicación de las Open Apps que han participado en el concurso, porque sin duda, y vista la gran calidad de algunas de ellas, van a servir de apoyo y fuente de conocimiento de la herramienta para los iniciados y también para los veteranos.
Tras la publicación de la nueva versión, dedicaremos un tiempo extra (hasta donde el trabajo y la familia nos lo permita), para examinar nuevamente la herramienta y dedicaré algunos articulos a evaluar y exponer las conclusiones obtenidas en dichas pruebas.
Estas pruebas se realizarán a conciencia, porque de los resultados obtenidos, tomaremos las decisiones correspondientes para abordar los futuros proyectos con V7.
Empieza a contar, 7, 6, 5, 4, 3, …
feb
17
Para comenzar la edición de un nuevo formulario, primero debemos indicar cual sera la tabla asociada al formulario, aunque este tambien podria ser un formulario sin origen.
Ahora que ya hemos indicado cual es la tabla de origen y un nombre para el formulario, puedes crear el formulario Vacío, o elegir uno de los bloques de distribución de los componentes del formulario.
Los formularios sin origen son muy útiles y necesarios para crear el marco principal de ejecución de la aplicación. Aunque no es su único uso.
Una vez elegido el formato, pulsa siguiente para continuar con el asistente o finalizar.
Si has pulsado el boton siguiente, en esta pantalla del asistente, puedes elegir como deseas que aparezcan los controles dentro del formulario.
Los “controles” son los diferentes “subobjetos” que podemos incorporar a un formulario como la edición de campos, textos estáticos, calendarios para edición de fechas, deslizadores, edición de campos de tipo objeto.
Si marcamos la opción Estirar controles, estos aumentaran de tamaño cuando el usuario modifique las dimensiones de la ventana que muestra el formulario.
En la siguiente pestaña Botones, podemos incluido los botones mas habituales que se pueden utilizar en todos los formularios, es decir, Aceptar, Cancelar, Eliminar, o botones vacíos para poder modificarlos posteriormente.
También podemos cambiar el orden de aparición de estos botones con las flechas arriba y abajo.
En la ultima pantalla del asistente, se muestra un pequeño resumen con la información utilizada para crear el formulario, y es un buen momento para decidir si queremos cambiar algo, ya que al pulsar el botón Finalizar, el formulario sera creado definitivamente.
Esto no significa, que posteriormente no podamos modificar o incluso eliminar este formulario, si no cumple con nuestras expectativas.
Así que, prueba, cambia las opciones y crea muchos formularios diferentes para saber cual es el estilo que mas te gusta para tu aplicación. Es la mejor forma de obtener buenos resultados.
Al finalizar ya tenemos creado el formulario, y quedara algo asi:
feb
16
Pues sencillamente la representación visual de un registro o ficha de una tabla de nuestra base de datos. Es el objeto que nos permite introducir, modificar o eliminar datos en un registro de una tabla de la base de datos. Mediante un formulario correspondiente a la tabla de “Clientes” podemos añadir nuevos clientes a esa tabla, y también podemos modificar los datos de un cliente o eliminarlo del archivo. Y para todo esto, podemos utilizar un mismo formulario de la ficha de clientes, o podemos utilizar un formulario diferente para cada operación.
|
