Al tiempo que estamos trabajando en el desarrollo de V7 estamos ya trabajando también en la migración de aplicaciones de V6 a V7. En el momento actual seguimos trabajando en la migración de estructuras de datos, la parte izquierda de vuestras aplicaciones, puesto que se trata de la parte más importante. Es ahí donde se encuentra la mayor complejidad, y donde, pese a que conservamos el sistema que ya teníamos en V6, aparecen cosas nuevas, por lo que debemos adaptar las estructuras de V6 a las que tendréis en V7.
Estamos todavía barajando el modo en el que funcionará el migrador, si éste será un editor de proyectos de V6 especial o un programa externo. En cualquier caso, tendrán la opción de generar una caja de datos a partir del proyecto que abramos en el migrador. Una vez que seleccionemos la opción de migración, previamente a realizar ésta, nos mostrará los errores que haya encontrado en el proyecto, para que podamos subsanarlos y migrar nuestra aplicación totalmente sin errores.
Una vez que hayamos realizado la migración, podremos abrir vDevelop y editar el proyecto así migrado, para realizar las modificaciones que consideremos oportunas. Hemos de tener en cuenta que pese a que V7 continúa la filosofía de V6, las aplicaciones de V6 no son compatibles con V7, y aunque el migrador hace un gran trabajo pasando la estructura de datos, tendremos que realizar modificaciones para que la nueva versión del proyecto sea totalmente funcional en V7.
Por otro lado, y debido a las características de mejora que tiene V7, habrá cosas que funcionen mejor en V7 por lo que no será necesario migrar ciertos elementos. Así, por ejemplo, veréis que no importaremos los históricos o plurales de una tabla, si no que los generamos de forma dinámica. Esto es porque en V7 los plurales serán dinámicos, no será necesario programarlos. De manera automática, cuando una tabla tenga un campo puntero a un maestro y éste se encuentre indexado, en el maestro se generan los enlaces plurales por cada uno de los índices disponibles, sin necesidad de programar nada, de ahí que no sea necesaria la migración.
En el punto actual de desarrollo, tal y como decimos, estamos en la fase de análisis y migración de la caja de datos, lo que incluye: tablas y tablas estáticas, campos, punteros y enlaces, índices, actualizaciones y variables globales. Esto no implica que una estructura de datos migrada de V6 a V7 pueda directamente funcionar sobre V7: tendremos que programar ciertos aspectos de nuestras aplicaciones para que se adapten al funcionamiento requerido.
Además, si queremos aprovechar toda la potencia que nos brinda V7: nuevos tipos de campos y variables como Alfa256, Latin1 ó UTF-16, nuevos tipos de índices como el Índice Complejo, nuevos objetos de la caja de datos como el objeto Constante, por supuesto, deberemos programarlos en nuestra nueva aplicación en V7.
- Valorar esta entrada
(Sin votos) - Comentarios (19)
- Comentar
- Imprimir
Por fjpnovo #
Entendido.
Un saludo,
Fran.
Por alvaro #
Buenas,
Es fantástico que ya estéis trabajando en una “pasarela V6 -> V7″
Pensaba que este programa lo empezaríais a anunciar para cuando se tuviera una versión al menos “candidata” de la V7 final. ¿Tal vez es que ya estáis cerca de alcanzar el hito de una versión estable?
El artículo me ha parecido muy informativo. Sobre si presentar el migrador como parte del editor de mapas o como un programa independiente… ¿Tal vez sea más usable integrarlo en el editor? Lo digo porque los posibles errores en objetos del mapa se le muestran al usuario y con el migrador integrado en el editor se puede comenzar a arreglar los errores directamente. Pero no sé, tampoco estoy seguro
Un saludo
Por eic #
Más o menos, lo que se había comentado desde el principio, con sus ventajas e inconvenientes.
Saludos,
Fran Varona
Por adelo #
Por jcmar #
Entendido y a la espera
Por jmmira #
Me aterroriza esta frase:
“Hemos de tener en cuenta que pese a que V7 continúa la filosofía de V6, las aplicaciones de V6 no son compatibles con V7, y aunque el migrador hace un gran trabajo pasando la estructura de datos, tendremos que realizar modificaciones para que la nueva versión del proyecto sea totalmente funcional en V7.”,
esto me recuerda los viejos tiempos en que Visual Basic sacaba una nueva versión y había que reprogramar todo lo anterior. Esta esperiencia con VB fué lo que nos llevó hacia Velazquez Visual y espero que no sea lo que nos saque.
La cuestión más importante es saber en qué porcentaje no es compatible.
Por eic #
Hola, jmmira.
En general, los cambios de versiones de Velneo fueron bastante tranquilos, y salvo pequeños detalles, todo fue siempre compatible hacia adelante. Pero esto no. Para nada.
Tengo la impresión (por lo que se ha comentado) que salvaremos “casi todo” de la parte izquierda, “casi todos los objetos” de la parte derecha (formularios y demás)… Pero habrá que revisarse lo verdaderamente importante: los procesos de todos los botones (p.ej.). Y como hay cosas nuevas (índices complejos…), algunas de las cosas que tendríamos previstas ya no valen, y habrá que rehacerlas. Vamos, que pasar una aplicación con algo de complicación en la gestión de eventos va a llevar “un buen rato”. Y no es que me moleste, es lo lógico cuando se ha hecho un cambio tan profundo. Otra cosa es que nos venga bien o no.
Saludos,
Fran Varona
Por fgutierrez #
Gracias a todos por vuestros comentarios. Los tendremos en cuenta en el desarrollo de V7.
Jmmira, no debes tener terror. Sí queremos dejar claro que las aplicaciones V6 no van a funcionar en V7, pero la herramienta de migración te va a permitir pasar tus aplicaciones de V6 a V7 y seguir trabajando con ellas tal y como explicamos en el artículo.
Debes tener en cuenta que el salto de tecnología desde V6 a V7 es enorme. Cosas que pueden parecer tan nimias como el formato de las imágenes, dejan de serlo cuando has de pensar que no son compatibles simplemente por el hecho de que los usados hasta ahora no son multi-plataforma. Como ese, muchos más, desde los menús y formularios que se funden, hasta los plurales o históricos que ahora son dinámicos.
Además estamos hablando de que en V7 tendrás acceso a una serie de nuevos elementos, como las acciones, formularios y menús se funden para facilitar el trabajo con ambos, aparecen nuevos tipos de campos como Alfa256, latin1, UTF-16, nuevos objetos como el índice complejo, paletas de colores que te resolverán el problema de diseño de formularios, rejillas y menús, la posibilidad de que tus aplicaciones sean multi-idioma, etc.
Todo esto, para poder aprovecharlo, deberás programarlo. Sería una pena pasar una aplicación de V6 a V7 y dejarla tal cual, porque no aprovecharías toda la potencia que tiene. Entendemos que la migración no debe ser una limitación para el desarrollo de V7.
Por daniel #
Hola a todos
Que hay muchos cambios es cierto, que los formularios y menus puede no merecer la peda migrarlos, estoy deacuerdo. Pero creo que con los procesos, funciones y las busquedas si se deberia hacer ese esfueszo puesto que hay procesos muy largos que hace años que estamos depurardo.
Por eso aunque luego los tengamos que reprogramar mereceria la pena.
Por daniel #
Otra Cosa he entendido que los ficheros no son compatibles. ¿como tenemos que pasar los datos?
Por info #
Muy Buenas a Todos
En relacion con esto quisiera plantear el siguiente problema o tal vez no. Al migrar las tablas ¿Van todas a una sola caja de datos?. Se pueden mover posteriormente de una caja de datos a otra, y esto me plantea un segundo problema que seria interesante ver si tiene una solucion. Al mover/copiar una tabla que esta siendo utilizada por otras tablas/objetos a otro objeto/tabla/sitio nuevo o ya existente ¿Seria necesario reprogramar? . Lo digo porque puedes una vez que vayas programando darte cuenta de que una determinada tabla es mas interesante que este en otra caja o sitio sitio sabrian rehacerse los nuevos !!mapas!!. Bueno no se si mas o menos me he explicado.
Un Saludo
Miguel Benjumea
Por fjpnovo #
Buenas tardes:
Coincido con Fran Varona en el tema de los procesos. Yo tengo aplicaciones con más de 3.000 procesos, si tengo que reescribirlos todos creo que no merecería la pena la migración.
Por otra parte supongo que los procesos también se podrán migrar. Digo esto por el aspecto que tenían los procesos en el editor mostrado en el último seminario… se parecían mucho a los actuales. ¿Estoy en lo cierto?
Un saludo,
Fran.
Por davidgu #
Muchas gracias por vuestros comentarios
Gracias a estos comentarios podemos entender vuestras necesidades y prioridades.
Tal como hemos detectado la migración es uno de los puntos más críticos para todos vosotros y por eso nos hemos puesto manos a la obra en este área desde hace unos meses.
Primero demos plantearnos que la migración a V7 no se parecerá en nada a los cambios de las versiones 6.x o 5.x.
Podemos partir de la idea que cambiamos prácticamente de producto. Uno de los planteamientos internos es que nada de v6 podía limitar el futuro de V7, si es compatible mucho mejor, pero no podemos limitarnos a hacer una copia de V6.
Dicho esto, todos demos plantearnos la migración a V7 como un proceso a pensarse y a tomarlo como un cambio importante.
Para este proceso tendremos todas las herramientas posibles y especialmente probadas para todas las combinaciones que tenéis en vuestros proyectos.
Como bien dice Fran, existen mapas con miles de objetos, dado las diferencias de una versión con otra podéis entender que si solo una línea de esos mil procesos no funciona adecuadamente el programa no funcionará como en V6 y vuestra experiencia de usuario en la migración será un poco frustrante.
Por estos temas, debemos pensar que esos elementos migrados deberán pasar un proceso por vuestra parte de análisis y revisión, y en muchos casos de cambio para adaptarse a la nueva versión.
Lo importante que queremos comentaros es la filosofía de la migración y no transmitiros que existirá la típica migración de “botón y todo funcionando”
Saludos
Por davidgu #
Respecto a la pregunta de Daniel, de pasar los datos, estamos barajando varias opciones dependiendo del resultado de la migración de las cajas de datos.
La que estará seguro es las funciones de V6 que permitirán dar altas en un servidor V7. De esta forma se permite ejecutar un proceso de migración basado en procesos de una aplicación a otra, incluso aunque las aplicaciones sean distintas.
Respecto a lo que comenta Miguel, creo que te hemos entendido. Realmente al mover una tabla de una ubicación a otra, lógicamente deberemos cambiar las relaciones de los objetos que apuntan a dicha tabla, ya sea por el inspector de objetos que lo usan o mediante algo un poco más automático.
Para hacernos una idea seria algo como cuando duplicamos una tabla y queremos que todos los objetos usen la tabla duplicada y no la origen.
De todas formas estamos en mente con algo estilo “buscar reemplazar” a nivel de objetos V7, pero no puede adelantarte mucho ya que todavía no ha pasado la fase de diseño.
Saludos
Por salvador #
Aunque me he sumado recientemente a todo este mundo de Velneo, os comprendo perfectamente cuando comentais que es duro tener un proyecto que tiene procesos con un numero grande de lineas (en mi caso funciones y procedimientos) y plantearse migrarlo a una nueva versión. Es compleja esa decisión por cuanto pueden haber proyectos que esten funcionando bien y que realmente no lo requieran de forma inminente.
Coincido tambien en que va a ser dificil que Velneo pueda simplificar ese proceso de migración de los proyectos, a nivel de proceso, debido al enorme cambio que se ha producido en la V7. Y creo que muchas empresas optarán por adoptar la V7 para nuevos desarrollos y mientras les sea posible seguir trabajando con la V6 en aquellos proyectos que sean complejos de abordar.
Mi impresión es que un porcentaje alto de los proyectos a migrar serán los pequeños ya que los grandes es una decisión demasiado compleja y no se abordarán a no ser que sea rentable. Al final lo que manda es el coste económico de dicho proceso de migración y no la buena voluntad.
No obstante, si que me parece que se ha abordado de una forma razonable y que ahorrará un monton de tiempo al menos en el diseño de las relaciones de las tablas, que tambien es una de las facetas claves de la aplicación.
Un saludo,
Salvador
Por daniel #
Todos en informatica hemos realizado una correlacion de sentencias y si se propone creo que no seria tan conplicado, entendiendo que siempre tengamos que optimizar.
De todos los modos y creo que no sea muy pesado lo primero es que de una vez tengamos una idea clara de las partes que no hemos acabado de ver del editor.
Por info #
ODBC Quiero plantear una duda. Al igual que existe un driver Micosoft text Diver ODBC para ficheros de texto, ¿es posible crear un DRIVER ODBC para Velneo? Para que otros usuarios puedan acceder a leer las tablas de Velneo. Esto es un asunto importante por el que hemos perdido algún cliente que nos planteaba el problema de en caso de algún problema como podría ler las tablas de Velneo, pienso que no somos el unico caso, pero es necesario compatiblizar de alguna manera o permitir mediante algún driver poder acceder a las tablas del Velneo.
Un Saludo a Todos
Miguel Benjumea
Por davidgu #
Estimado Miguel
Efectivamente, la apertura a nuestra base de datos desde herramientas de terceros era una necesidad que V7 debía solventar.
En el último seminario comentábamos algo de este punto en el que informábamos de las primeras pruebas internas de este driver ODBC.
Al considerarse de vital importancia para V7, el driver ODBC se esta avanzando en paralelo al desarrollo del vDataClient ( Cliente de datos ).
En ambos casos tanto el vDataClient como el driver ODBC se conectan por VATP al servidor vServer como un cliente de datos, uno tiene un interface de usuario y el otro un interfaz con el gestor de conexiones ODBC del sistema operativo. Nuestro planteamiento es que el driver ODBC pueda beneficiarse de las ventajas del VATP y así que el uso del driver sea mucho más efectivo.
Saludos
Por info #
Me alegro profundamente de lo que comentais sobre el ODBC.
Muchas gracias por la respuesta.
Un Saludo
Miguel Benjumea