Este debate contiene 28 respuestas, tiene 9 voces y lo actualizo [N3] cribera hace 2 años, 4 meses.
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
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
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….
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
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?
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
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….
@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
@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…
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?
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.
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.

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.
Bueno estoy de acuerdo con todas las opiniones pero pienso que en la medida de lo posible “Life can be much Softer”
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
Debes estar registrado para responder a este debate.



