Crear aplicaciones sobre una BD existente (PostGreSQL en mi caso)

Velneo
1

Estoy preocupado sobre el acceso nativo a POSTGRESQL  … Aquí, en el 2007, dijeron que habría acceso NATIVO http://velneo.es/comandos-de-conexion-con-bases-de-datos-externas/

.

Sin embargo, lo unico otro nuevo sobre el tema es esto... http://velneo.es/tutor-de-acceso-a-base-de-datos-externas-10/

Pero leo que se refiere a importar datos a una tabla temporal....eso no parece acceso nativo, para nada...o estoy equivocado?

EDITO esto mas http://velneo.es/acceso-a-bases-de-datos-externas/ aparecen mejoras...pero aun asi no me queda tan claro lo que pregunto luego...por eso no lo elimino, por si acaso lo pueden contestar de forma mas explciita....

.

La idea que yo tenia es que....uno pueda tomar una BASE DE DATOS EXISTENTE y crear

aplicaciones Velneo SOBRE LA BASE EXISTENTE....

.

Esto es un caso que se da mucho en el mundo real, uno no puede ir a una organizacion gubernamental o a una transnacional y decirles que desechen su base de datos, que ahora guardaran todo en Velneo....

.

Ademas, piensen que tendriamos que volver a crear cientos de tablas en Velneo, una por una, con sus llaves, relaciones, indices, constraints, triggers, stored procedures, etc......

.

Al menos en la herramienta mas RAD que habia tenido hasta ahora, esto se hacia de forma natural...

La aplicacion uno la podia hacer sobre MS-SQL, y luego cambiar en un solo lugar a nivel de aplicacion (y se podian cambiar las definciones de tablas en batch tambien) , generalmente una pequena app donde se ponian los parametros de conexion para acceder a la misma definicion, pero en PostGreSQL, una vez hecho esto, re compilaba y listo, la aplicacion accederia a otra base de datos....

.

 

.

Idem con una base de datos existente, se podian importar las definiciones de esa base existente a lo que en Velneo  llaman proyecto de datos, y quedaban las tablas, indices, contraints, etc...creadas en el proyecto de datos de una sola vez.....

.

Una vez importada esa definicion, uno podia construir un front end sobre esa base de datos....

.

He buscado en Velneo y no veo eso posible, es decir, que la aplicacion Velneo escriba directamente sobre la base PostGreSQL....asi que quisiera confirmalo....

.

Si hay una base de datos ya existente, hay forma de importar todas esas definciones a un proyecto de datos en Velneo?

.

Hay forma de hacer aplicaciones en Velneo sobre esa definicion, pero haciendo transacciones en tiempo real, sobre la base PostGreSQL existente y no sobre la base de Velneo?

.

Disculpas si la respuesta es muy obvia y no supe buscar...pero necesito cerciorarme por favor.

Gracias de antemano por las aclaraciones. Saludos, Cesar

 

 

 

 

2

Hola Cesar, para tus dudas las siguientes anotaciones:

 

1. No recuerdo que Velneo nos haya creado la espectativa de que las aplicaciones v7 corrieran directamente sobre otros motores, lo que si se nos dijo era que podiamos acceder a esos motores para consultar e insertar data necesaria (cosa que se agradece al dia de hoy).

 

2. Aplicar el enfoque RAD a Velneo no aplica, V7 no es un RAD y no prentende serlo, de hecho poco sentido tendria sin la potencia de la union directa con su base de datos.

 

3. de momento no se pueden realizar migraciones de los Schema de otros motores, pero me gusta tu idea, por supuesto habria que aplicarse una reingenieria para aprovechar toda la portencia del motor de datos de Velneo.

 

espero haberte ayudado,

 

Saludos

 

 

3

Cristian, gracias por responder...Espero podamos desmenuzar el tema...tratare de ordenarlo a tu estilo

1.-Yo soy usuario nuevo, asi que no se que les prometerian a los de la 6X. Mis expectativas,  fueron cosas que lei en el mismo foro de Velneo me parece, cuando se comparaba con Windev, en mi caso, yo venia de Clarion y miraba todo de palco...Pero tanto en Clarion como en Windev se pueden construir aplicaciones sobre bases de datos ya existentes y con datos ya almacenados....

.

Esto me parece algo ESENCIAL para un desarrollador, o sino dime....crees que es facil decirle a una empresa grande que tire su robusta  BD transaccionalmente probada?...no seria mas facil convencerlos el desarrollarles apliaciones sobre esa base ya existente?

.

Clarion tenia su formato propietario, pero te convertia su lenguaje a consultas, cuando cambiabas de motor....a SQL especifico para el motor destino, esto no ten todos los casos, cuando era ODBC a ANSI-SQL...pero el punto es que podias desarrollar sobre una base de datos existente, y  eso ayuda MUCHISIMO...

Sino, estarias condenado a usar tu herramienta, SOLO PARA DESARROLLOS NUEVOS, y al menos en mi caso, eso limitaria mucho el uso que puedo darle....

.

ME gustaria confirmacion por parte de Velneo, que debemos DESCARTAR VELNEO para desarrollar aplicaciones que operen en tiempo real, y a nivel transaccional, sobre bases de datos ya existentes....es cierto?

.

2.-Porque Velneo no podria ser RAD? al menos en lo que he podido ver, podria convertirse en una RAd sin perder esa union directa con su BD interna....con solo poner en modo batch elementos prearmados de Velneo, juegos de Rejillas, Formularios, busquedas, locators, acciones, etc...

Y esto podria mantenerse aun con acceso a BD externas...Es largo de explciar, pero tengo algunas pantallas para intentar aclarar a que me refiero...Y mi punto, es que si son capaces de lograr lo que han hecho con Velneo, dar ese otro paso no deberia suponer mayor problema...Idem con el acceso a bases de datos externas....

.

3.-Si lograran hacer eso, solucionarian parte del problema, evitando volver a crear cientos de definciones de tablas y sus elementos que ya estaban definidos en un motor de BD...pero de todas maneras, seguirian sin permitir construir aplicaciones Velneo que operen directamente sobre los motores y los datos ya almacenados....No crees?

.

Me olvidaba, para mas INRI...en mi caso, yo tengo que usar PostGIS, y en la base de datos de Velneo no hay nada equivalente, como para hacer Spatial SQL....cierto?

Como ves, al menos en este proyecto, es inexcusable mi base de datos sea PostGreSQL o alguna que soporte Spatial SQL...por eso yo tenia la idea que usar Velneo para desarrollar en Front-End y que el backend sea PostGreSQL/PostGIS...Se entiende?

.

Seguramente en otros rubros, apareceran casos asi....

 

 

 

4

Hola.

Como comenta Cristian, Velneo no está pensado (al menos, actualmente) para desarrollar aplicaciones directamente sobre otras bases de datos. El acceso a bases de datos externas se refiere al acceso "puntual" (de lectura y/o escritura) a otras bases de datos. A ese acceso se le llama "nativo" cuando no necesitas tener un driver externo instalado, sino que el propio Velneo gestiona el controlador de acceso a esa base de datos.

Algo se comentó, en la presentación del año 2009, por el mismo Juan Muñoz Cobos, de la posibilidad de que en un futuro se pudiesen tener objetos (rejillas...) definidos sobre tablas externas... pero no volví a oír hablar de ello. 

Por supuesto, lo que planteas tiene sentido (Velneo "podría" convertirse en un RAD sobre cualquier base de datos) pero, de momento, no es lo que pretende.

Saludos,

Fran Varona

 

 

5

Pues me encuentro algo shockeado con esto....yo daba por hecho que Velneo permitía desarrollar sobre Bases de Datos existentes...

.

Es algo que Clarion ya hacia en 1997, cuando empeze a usarlo (y si no me equivoco, lo hacia de mucho antes)...de hecho, incluso practicamente todas las herramientas que he usado, me permitian esto, mas bien me cuesta pensar en una herramienta que no lo permita (quiza por buscar siempre herramientas independientes me habia llevado a esto)...

.

Siempre tuve esa libertad como algo que cualquier herramienta (una que no sea casada con algun vendedor particular de BD, y ni asi) deberia garantizar....es como un estandar implicito en el desarrollo de software, creia yo....

.

Es que no me puedo hacer a la idea que con Velneo no podré constuir nuevos front-end para aplicaciones existenes, o modificarle funcionalidades o incluso agregarle tablas, pero todo ya desde Velneo....

.

Ustedes acaso nunca han tenido, como desarrolladores, la necesidad de
desarrollar aplicaciones sobre una Base de Datos ya existente? (por ejemplo, hacer sistemas de optimizacion, o de DataWarehousing, basandose en datos de un ERP )

.

,...y encima  entero que estaria obligado a construir los cientos de tablas, llaves, relaciones, todo desde cero....No puedo entender como pueden hacer cosas tan complejas en algunos casos, y no puedan hacer cosas que otras herramientas hacen desde hace muchisimo tiempo atras....

.

Creo que seria bueno que adviertan eso de entrada, para que personas que si o si necesitan construir aplicaciones sobre otras bases de datos, tengan esto en cuenta al momento de decidir, antes de embarcarse en Velneo, seria justo, no les parece?

 

 

6

Ahora me lo miro mejor, que voy liadete, pero, igual que en:

http://velneo.es/acceso-a-bases-de-datos-externas/

hace un recorrer lista, también se podrá de alguna manera retornar lista.

Aunque no lo he probado aún, y lo tengo en mi ToDo (porque los drivers nativos fuera de Windows no vienen para postgres, y hay que compilarlos) trabajar con una BBDD externa, poder podrás, pero no será tan cómodo y sencillo (y habría que mirar la velocidad) como trabajar directamente con Velneo. Supongo que no podrás tener las rejillas autoconectadas a la BBDD si no que tendrás que alimentarlas con procesos, pero, como digo, a falta de haber hecho ninguna prueba, seguramente poder se puede..otra cosa es que sea más o menos complicado/cómodo.

Apostaría a que casi seguro en un futuro estará. Y lo lejos que se encuentre ese futuro depende de nosotros. http://ideas.velneo.com mi voto está asegurado

7

La idea ya esta creada: http://ideas.velneo.es/forums/61867-ideas/suggestions/1385231-desarrollar-directamente-sobre-bases-de-datos-exte

Les invito a votar para tratar de que llegue a primera pagina y vean la idea...

A mi al menos, Velneo, asi con esta limitacion, para el proyecto que yo lo queria (Base de datos existente PostGreSQL+PostGIS), no me sirve....

Quiza si agregan capacidad espacial (Spatial SQL) a la base Velneo (seria otra idea a agregar pero ya me quede sin puntos, je je), mejoraria en algo la situacion...aunque igual quedaria la lata de importar toda la base y los datos, al menos se podria constuir lo que necesito....

Pero asi como esta, ni puedo hacer Spatial SQL en la base Velneo, ni tampoco puedo desarrollar sobre la base que si puede hacerlo...Pues como que estoy atorado....

 

8

@Cjribera

Creo que seria bueno que adviertan eso de entrada, para que personas que
si o si necesitan construir aplicaciones sobre otras bases de datos,
tengan esto en cuenta al momento de decidir, antes de embarcarse en
Velneo, seria lo justo, no les parece?

Cuando miro una herramienta, no necesito que me adviertan de lo que no hace, ¿Que herramienta, marca o empresa te dice lo que no hace?

Yo que si necesito, es saber lo que hace, el resto lo puedes averiguar por deduccion logica o preguntando a la propia empresa.

Esto en un proceso hecho en velneo quedaria asi:

 

Cesta: Limpiar ( QUE-ME-HACE-FALTA )

Cargar lista ( FUNCIONALIDADES , ID )

--- Cesta: Quitar lista ( ESTO-YA-FUNCIONA )

--- Añadir lista a la salida

 

Si a la lista principal de tus propias necesidades , quitamos lo que ya esta hecho, nos queda lo que no hay.

Pero esta logica, no es valida solo para Velneo, es valida para todas las herramientas.

Lo que realmente tienes que valorar es si lo que hay te es util y para que tipo de aplicaciones lo vas a aprovechar.

En el futuro, espero que nos permitan muchas mas cosas, y para eso, hay que empezar a pedirlas con tiempo, y es lo que suelo hacer en todos los post con ideas que escribo. Si quieres que publique estas y otras ideas que puedas tener, solo tienes que pedirmelo. En el blog tienes mis datos de contacto.

un saludo

Jose Luis

http://www.ascsl.com

9

@Pepeto....

Pero es que esto siempre fue algo taaaan posible, nunca imagine encontrarme con una herramienta no atada a un gran vendedor de BD, que me prohiba desarrollar encima de otras bases de datos....

.

Incluso PowerBuilder que es de Sybase, permitia en las pruebas que me mostraron, desarrollar sobre PostGreSQL via ODBC....Creo que el Oracle Developer2000 es el unico que recuerdo haber visto que no permitia....

.

Encima como anunciaban la conectividad hacia otras bases de datos, como uno de los hitos de la V7, sobre la 6X, supuse que se referia a lo que habia visto en Clarion (desde 1997), Netbeans, Windev, Eclipse, Delphi, Visual Studio, etc...

.

Mea culpa entonces por no desconfiar mas :-(

Como ya estoy embarcado, no queda mas, en mi caso, esperar que la idea prospere, o que habiliten capacidades espaciales (equivalente a PostGIS) en la base nativa de Velneo (esto ultimo creo que tecnicamente es mas dificil aun de lograr,  es de menor interes general, y por ultimo ya no me quedaria mas que 1 punto para dar....asi que lo veo como caso perdido tener soporte geografico  en la base Velneo).

PD: @Giuseppe::Komenco Gracias por el voto...espero lleguen mas...

 

 

 

 

 

 

 

 

 

10

No tengo ni idea lo que es PostGIS pero...a estas capacidades de postgres, no puedes acceder a través de SQL?

Cito de nuevo mi anterior post:

Ahora me lo miro mejor, que voy liadete, pero, igual que en:

http://velneo.es/acceso-a-bases-de-datos-externas/

hace un recorrer lista, también se podrá de alguna manera retornar lista.

Aunque no lo he probado aún, y lo tengo en mi ToDo (porque los
drivers nativos fuera de Windows no vienen para postgres, y hay que
compilarlos) trabajar con una BBDD externa, poder podrás, pero no será
tan cómodo y sencillo (y habría que mirar la velocidad) como trabajar
directamente con Velneo. Supongo que no podrás tener las rejillas
autoconectadas a la BBDD si no que tendrás que alimentarlas con
procesos, pero, como digo, a falta de haber hecho ninguna prueba,
seguramente poder se puede..otra cosa es que sea más o menos
complicado/cómodo.

Lo has probado?

11

Aqui todo gira en una palabra mal usada: "acceso nativo".

 

Desde luego sería muy deseable lo que comentas. Entiendo y comparto tu postura y experiencia. Las grandes empresas tienen sistemas variados y sería muy potente poder complementarlos usando velneo sin descartar o perder el tiempo en volver a redefinir lo existente que está probado y funciona.

 

Para ello tendría que potenciarse este aspecto de integración más allá que simples accesos por ODBC o drivers "nativos". Votaré por tu idea.

 

Saludos.

12

No estoy de acuerdo, la palabra está bien empleada.

Acceso nativo = Accede a una bbdd a través de un driver específico para esa bbdd (y no por ODBC, OleDB etc.. que son capas intermedias).

En las palabras Acceso Nativo, no se implica que puedas interconectar los objetos de Velneo con esa BBDD on the fly. Velneo puede acceder a PostgreSQL, y puedes lanzar SQL (select, insert, update, delete, etc....) a esas BBDD a través del driver nativo, otra cosa, es, como digo, que puedas conectar una rejilla directamente a una consulta/tabla.

13

Me parece que lo del acceso del V7 a otras sistemas de Bases de Datos es algo que siempre quedó más o menos claro.

Velneo hasta ahora siempre busca la comunicación con otros sistemas de gestión de datos pero nunca la integración al 100% . En realidad el modelo de gestión de datos de Velneo es muy diferente al de un sistema de bases de datos relacional.

Es un sistema RAD especializado en sistema de gestión sobre su propio modelo de datos. Clarion por lo que tengo entendido es un RAD para varias bases de datos relacionales...al parecer algo descontinuado.

Seguramente Clarion tiene sus ventajas y desventajas sobre el V7 pero ya se habló mucho de comparaciones con WinDev, Clarion, Genexus, .NET, Java y demás entornos con Velneo. Cada uno tiene su historia y sus objetivos...hay que ver si están de acuerdo con los de uno.

No veo ningún inconveniente en migrar un sistema grande de unas 200 tablas o más al V7 ni la comunicación con otros sistemas.

Lo que si creo que se habló en su momento es de hacer una especie de mapeo estático de objetos de Velneo a una base de datos relacional.

La tecnología ODBC es antigua, el rendimiento es muy pobre.

La comunicación con la base de datos de Velneo me parece que si se debería mejorar como quizás también mejorar en la comunicación con otras bases de datos. Siempre hay muchas cosas por mejorar... el v7 es un sistema que recién está madurando.

Saludos.

Emanuel Toro.

14

Bueno estoy de acuerdo con todas las opiniones pero pienso que en la medida de lo posible "Life can be much Softer"

 

15

Bueno estoy de acuerdo con todas las opiniones pero pienso que en la medida de lo posible "Life can be much Softer"

 

Si está claro, pero el problema, como comentan, es, cuando llegas a un cliente que trabaja con un ERP montado sobre Oracle por ejemplo. Y te pide que hagas cierta aplicación aprovechando los datos que ya tiene en ese servidor. Por mucho que le quieras vender la moto, él tiene comprado el ERP, Oracle y lo tiene todo montado. Si cada vez, hay que importar todos los datos necesarios a una BBDD local en Velneo, trabajar sobre ella, y replicar de nuevo, no es óptimo que trabajar directamente sobre la BBDD

16

dos cositas:

Una vez aplicar el enfoque RAD no aplica V7 almenos no en este momento, si bien podria pensarse que Velneo desarrollara un ORM interno para manejar diferentes bases de datos (Yo programo sobre ActiveRecord en Ruby y la filosofía de navegación de datos es muy similar y funciona casi sobre cualquier cosa), pero aun asi no creo y de serlo tardaria mucho el vServer es 50% servidor de aplicaciones y 50% servidor de datos y la arquitectura pareece esta demasiado unida a este concepto.

 

Con respecto a la situación cuando deben migrarse BD a Velneo, vengo reclamando hace un tiempo estadisticas de capacidad y Stress para un Vserver, con cuantas Gigas puede, con cuantos usuarios se cae el servicio, cuanto es el rendimento en x millones de registros relacionados y no relacionados, etc. ustedes crearon el vServer y asumo lo han probado hasta sus limites y ese seria un poderosisimo argumento en una propuesto.

 

creo que todos sabemos y le tenemos fe a las prestaciones de un vServer pero el hecho es que no hay data, me encantaría hacer esa comparativa con otros motores pero debo admitir que no los conozco lo suficiente como para atreverme a hacer una comparativa de verdad.

 

Saludos

 

 

 

 

 

 

image

image

17

Para quien pregunto, Esto es PostGIS http://es.wikipedia.org/wiki/PostGIS En resumen? convierte a PostGreSQL en una BASE DE DATOS ESPACIAL.... (Habilitar el uso de SPATIAL SQL, no de SQL normal)

.

Esto se usa para SIG (Sistemas de Informacion Geografica), un campo que es muy rentable para los desarrolladores de software a nivel mundial (España dudo que sea la excepcion).

.

Lo otro es simple, no solo que es optimo poder desarrollar con Velneo sobre una base de datos existente....imaginen este escenario...

.

Llegas a una empresa de Telecomunicaciones, queriendo ganar un proyecto de desarrollo, con el cuento de que tendran que prescindir de su recontra-probada base de datos de altisima carga transaccional 24/7.......Para empezar de cero con otra base que probablemente ni su personal informatico conozca, ni siquiera de oidas...

.

Saben la hostia que te van a meter, por atreverte siquiera a sugerirles algo asi....? ....Despues de la hostia, les diras seguramente 'esto quiere decir, que del trabajo, ni hablar?' ;-)

.

Ese es mi punto, desarrollar sobre bases de datos existentes no es algo que sea simplemente 'deseable' ...en el mundo corporativo es IMPRESCINDIBLE....al punto que, entre que la base de datos Velneo no tiene capacidad espacial (equivalente a PostGIS)....y tampoco me permite trabajar sobre la base PostGreSQL/PostGIS ya creada....pues como que no te deja opcion para usarla en el rubro de sistemas SIG, o me equivoco?

 

 

18

Hola chikos aqui mi humide opinion, Velneo es una herramienta que te permite hacer todo de manera simple transparente y con una potente bd, crearte un modelo de negocio basado en su vServer que es la parte de central de todo, que haya acceso a otras bd es para obtener data o enviar a otros sgbd informacion que necesiten para ser administrados por otros sistemas en otros lenguajes, es una opcion necesaria ya que en el mundo real no existen un solo sistemas andando en la empresas, DONDE ESTA LA POTENCIA DE VELNEO: JUSTAMENTE EN SU BD ES UN PRODUCTO CON CARACTERISTICAS UNICAS QUE NO ENCONTRARAS EN NINGUNA HERRAMIENTA, por lo que no tiene ningun sentido pensar que usaras velneo para desarrollar sobre otra base de datos, si es asi velneo no es esa clase de herramienta, que te permita acceder para obtener o dejar datos a otros sistemas no significa que pueda reemplazar la bd de velneo por cualquier otra por que simplemente los objetos propios de velneo solo funcionan y su potencia radica en que solo lo hacen con su bd, ahora la respuesta es simple, si pues tendrian que cambiar toda su bd a velneo, pero es un "costo", que se pagara con desarrollo mas rapido limpio y tiempos de respuesta en mantenimiento como ninguna otra herramienta, velneo no es un lenguje visual de programacion como .net, etc es una caja completa para aplicaciones de gestion, yo por ejemplo tengo mi empresa si me enfrento a este dilema tengo 2 opciones o les propongo un sistema 100% velneo o me subcontrato gente para seguirle dando mantenimiento a lo que tienen o cambiarles las mascara para hacer los formularios, pero desde un punto de vista "velnisitico", ninguna bd hace las cosas como las hace velneo te recomiendo que chekes mas que realmente hace y como lo hace velneo, no es un lenguaje de programacion es una herramienta que te permite desarrollar nuevos modelos de negocio. Espero que esto te ayude en algo, y poco a poco usando la herramienta te convenzas de lo poderosa que esta herramienta.

Slds desde Peru

19

Me faltaba algo, ejemplo ORACLE DEVELOPERSUITE funciona perfecto contra Oracle, funcionara o no funcionara contra mysql o contra velneo o postgres o etc y si funcionace lo hara igual,  a  lo que voy cual es el sentido de usarlo contra otro sgbd si esta creado optimizado y su potencia se desplega contra su propio motor que es oracle, siendo asi el problema es el mismo pero la solucion en velneo es mas rentable y mas rapida eso te lo puedo asegurar.

Que se necesite una herramienta que te permita exportar toda una estrucutra de bd de otro gestor a velneo podria ser, pero, pero, pero, las cosas en velneo se hacen diferentes (tablas maestras, submaestras, arboladas, etc, actualizaciones, punteros contiguo hermano etcetctetctetctetct ves son muchas cosas que otros sgbd no exiten = tendrian que definirse),una importacion de ese tipo siempre terminara redisenandose sino preguntales a los de velneo 6.x.

Miralo de esta forma en un mundo de cloud computing, saas,paas, etc con que herramienta vas a desarrollar para enfrentar este nuevo paradigma, donde no sabras que cliente usaran tus usuarios linux windows mobile etc. quiza velneo ya esta hace tiempo en esa linea al apostar el uso de tecnologias multiplataforma tipo Qt, entre otras, creo que deberiamos pensar menos en solo desarrollo sino como empresa como negocio que me conviene mas, quiza me atrevo a decirte que ciertos sistemas o cambian o cambian, de nosotros depende hacerlo rentable, quiza para este caso como te dije mas arriba no te conviene o no te aprueban un cambio total sobre velneo entonces hazlo sobre un lenguaje visual y subcontrata no todo tenemos que saberlo, pero si aun asi te consume tiempo quiza el nicho de mercado y las ganancias estan por otro lado y estamos aislandonos en algo que quiza nos consuma demasiado tiempo, dinero y tranquilidad.

Slds

 

 

20

@JuanJex... no puedo creer es que trates de trivializar la limitacion para una herramienta, el hecho de que solo puede trabajar con su propia base de datos, y no es capaz de trabajar sobre una base de datos existente en cualquiera de los motores mas usados del mundo corporativo....

.

como ya dije en mi anterior post....no se trata de si es mas poderosos, mas limpio, mas bonito, hacerlo con la BD propietaria de Velneo...se trata del MUNDO REAL.....ese que justamente mencionas con tu discurso de cloud computing, PAAS, SAAS, multiplataforma, etc....

.

Tu dices " 2 opciones o les propongo un sistema 100% velneo"

Pues prueba decirle eso, un sistema 100% velneo, descartando su base ya existente.... a una de las empresas mencionadas antes (un banco, una empresa de telecomunicaciones, o cualquier empresa con altisima carga transaccional)....solo prueba, a ver que te responden.....o que van a opinar de tu seriedad como profesional....

.

"o me subcontrato gente para seguirle dando mantenimiento a lo que tienen o cambiarles las mascara para hacer los formularios"

Si sigues este camino......cual seria el punto de comrparse Velneo entonces, si al final estaras subcontratando?

Cuando uno compra una herramienta del estilo de Velneo, es para prescindir en gran parte de la dependencia de muchos programadores y el engorroso proceso de ello...

.

Sobre trabajar con otros motores de BD, yo creo que es tecnicamente posible, que no digo facil..... seria hacer un mapeo ORM...y en los objetos (Formulario, rejilla, informe), convertir sus funciones y comandos....a codigo SQL equivalente en la base de datos objeto... Clarion mismo  hacia algo asi ya en 1997.....podias controlar todo desde la aplicacion Clarion con su formato propietario de datos... o podias convertirlo en una herramienta para desarrollar un front-end sobre un motor ajeno...

.

Muchas cosas que hace velneo son muy buenas, que no se hacen en otras herramientas, por ejemplo un ID de una tabla padre apuntado 2 veces en la tabla hija (En mi ejemplo Chofer y Propietario son Entidades distintas, pero se puede haber 2 EntnidadID en la tabla camiones y el sistema lo toma de entrada, sin mas)...eso me parecio muy buen y no viene por default en otras herramientas...y seguro hay mas cosas asi..... pero al menos lo del ejemplo.... no deja de ser posible emularlo con tablas en memoria, para bases de datos que no soporten esto de entrada...

.

...Ese es mi punto....Velneo deberia extremar recursos para no quedar catalogado como una herramienta que solo funciona para su BD propietaria, imposibilitada de hacer aplicaciones sobre Oracle, MySQL o PostGreSQL....

.

Incluso como primera etapa, se podria hacer que trabaje con un ODBC universal, estandar SQL92....no importa la perdida de rendimiento, pero se lograria dejar el estigma en esta primera fase, peor es no poder usar los objetos sobre ninguna base externa, como pasa ahora, no creen?...

.

y ya gradualmente, ir construyendo drivers nativos (traducciones SQL ya optimizadas para cada motor de BD) para los principales motores....creen que es posible?