FoxyDB VS. SQLDATA

[diegod...@gmail.com]

Hola, a todos

 

                Desde medidados del 2015 incursionamos en FoxyDB en nuestra empresa para migrar las tablas nativas a motor de datos. 

Por la presión de los compromisos cotidianos no logramos avanzar mucho:  Normalizamos las más de 300 tablas del sistema y generamos un módulo para cargar datos históricos de nuestros usuarios desde la vieja estructura de tablas libres al nuevo modelo de datos en MariaDB.

Posiblemente ahora tengamos el tiempo para migrar todo el sistema, y quisiera saber si en términos generales la comunidad recomienda la clase FoxyDB de Antonio Meza, o la clase SQLDATA de Germán F. Valdez.

 

Nuestros primeros pasos fueron con FoxyDB, y nos sentimos muy cómodos. La limitación es que aún no podríamos ofrecer SQL Server u Oracle a cierto perfil de usuarios potenciales de nuestro sistema.

Entiendo que SQLDATA no tiene ése problema, pero trabaja con Cursoradapter y algunos han comentado en éste foro que no es la opción más eficiente en términos de performance.

 

Independientemente de las opiniones que espero recibir del foro, asumo que los dos desarrollos son excelentes, y agradezco la generosidad de Antonio y German.

 

Saludos,

Diego.-

 

 

[Irwin Rodriguez]

Ambas librerías son excelentes pero si me tengo de que decidir por una entonces elijo la DLL de Germán por ser portable, a la hora de cambiarme de lenguaje me llevo la librería y no tendría que rescribir el código de la misma para llevarme su lógica.

Saludos...!

--

DISTRIBUIDORA IRSESU, C.A

J-29947174-7
Irwin Rodríguez - Director

Analista Programador - Freelance
+584125210679

Barquisimeto - Venezuela
Desarrollos online dentro y fuera del país

[Antonio Meza]

El problema no es la tecnología que se use, es decir ODBC o ADO, o CursorAdapter, es mas bien que tanto se domine, porque ADO puede ser mejor pero si no se domina puede que alguien con buenos conocimientos de ODBC lo supere, y esto no quiere decir cual tecnología es mejor si no simplemente cual se domina mas.

Para agregar cualquier otro motor solo faltan pequeñas rutinas que lamentablemente no hay un estandar SQL y cada servidor lo hace de diferente manera y es cuestión de solo agregar esas diferencias al código y estaría trabajando con mas servidores.

Si manejaste capas en tu diseño no deberías tener problema de cambiar de FoxyDb a SqlData o incluso combinar ambas, pero si no separaste capas pues si sera un desafió cambiar o complementar ambas.

Si manejas bien SqlServer y Oracle te paso lo que necesito para agregarlos tu realizas las pruebas y comentas los resultados pues no dispongo de estos servidores para realizarlas.

saludos

Antonio Meza

[integral]

Estimado Amigo DIEGO .

Estoy totalmente de acuerdo con los comentarios del colega ANTONIO MEZA.

Te diré que yo mismo me hice esa pregunta hace un par de meses.

Hay que conocer bien del tema para poder manejar e implementar cualquiera de los dos codigos FoxyDB VS. SQLDATA sin desmerecer el trabajo realizado por los autores..

Al final por cuestión de tiempo y resultados decidí utili-zar ADO. 

Bueno ese es mi humilde opinión.

Saludos,

INTEGRAL 

[Alejandro Garcia G.]

Saludos, hasta hace poco tiempo he estado trabajando con SQL, y honestamente no sé con que tecnologia estoy trabajando. Y realmente no me he dedicado a buscar cual es. Me pueden dar alguna luz adicional para saber con estoy trabjando, no se, tal vez un ejemplo de ambas tecnologías o algo así.

[Carlos Hidalgo]

Amigo Alejando...

Creo no  estas usando ninguna.. sino que estas trabajando con comandos y funciones del sublenguaje Structured Query Language (SQL)  que soporta  FoxPro..

 

FoxyDB y SQLDATA  son librerías creadas por miembros de este foro para trabajar (interactuar) con un Servidor (SGBD)

Tendrías que descargarlas para poder usarlas. (traen ejemplos) y por lo que preguntas asumo que no has descargado ninguna...

Saludos

Felices fiestas de fin de Año.. 

[Alejandro Garcia G.]

No, si las descargue, ambas me funcinaron bien con los ejemplo mas no he tenido la oportunidad para estudiarlas a fondo... quizas en este nuevo comienzo de año que las cosas son mas tranquilas pueda hacerlo...

Gracias.

[diegod...@gmail.com]

Gracias, Antonio.

 

                               Se trata de una aplicación grande, y no está muy ordenada. Sólo algunos módulos están desarrollados en capas  (…los módulos desarrollados en los últimos años).

 

El nuevo modelo de datos que desarrollamos (MariaDB) es muy diferente al original (DBC), y por eso las consultas para la carga de los cursores son bastante complejas.  

Muchas tablas acumulan millones de filas en pocos años, porque es un sistema de trazabilidad por RFID. (…queremos ser cuidadosos en la cantidad de filas que se cargan a los cursores, para poder abandonar al fin la tecnología RDP.)

Y generalmente hay muchos usuarios concurrentes, 24 x7.

 

Dudé antes de mandar el post, porque temía provocar un debate acalorado. Pero no hubo respuestas contundentes.

¿Sugerís que avancemos con FoxyDB?

 

Saludos , gracias.-

[Esteban H.]

Hola Diego.

Comparto las palabras de Antonio, el buen uso de una tecnología hace a la eficiencia.

X otro lado, de querer salir de las tablas libres de VFP y aprender otro sistema de almacenamiento no elegiría nunca CursorAdapter, si me pondría a trabajar con algún motor SQL. Cuál elegir, depende de gustos y si se quiere gastar o no, en mi caso yo elegí Firebird dado q es totalmente gratis y trabaja tanto en Windows como en Linux y accedo al mismo a través de ODBC. Dicen q el trabajar con ADO sobre SQL es más rápido, pero requiere de más trabajo y en Firebird las librerías de ADO son pagas, x ahora lo desestimé totalmente.

Hace un tiempo atrás conversé con Pancho q ha trabajado con SQLServer a través de ADO, pero realmente es muy difícil precisar cuál es mejor.

En cuanto a q librería elegir, no he probado ninguna de las 2, pero es bueno agradecer a quienes decidieron gastar parte de su tiempo p hacer más fácil el acceso a los programadores de la comunidad VFP a los motores SQL.

 

Saludos

 

Esteban.

[Germán Fabricio Valdez]

la sqldata.dll usa proveedores de ADO (oledb y odbc) de 32 bits que proporcionan los motores de bases de datos, no es necesario comprar nada

la sqldata.dll funciona desde el 2006 inicialmente con SQL server 2000 y no pare de mejorar la clase hasta sql2016

he añadido nuevos motores como oracle,mysql,mariadb,firebird,postgresql y he hecho pruebas y hay que hacer algunos cambios en la tecnica de programacion
para insertar registros y recuperar el ID generado, o los IDs generados en algunos motores como firebird y postgresql

ademas algunos motores necesitan releer el registro insertado si se quiere modificar los datos como por ejemplo postgresql

en el archivo sqldata.rar estan los ejemplos y las instrucciones.txt

nunca he tenido problemas con cursoradapter

[diegod...@gmail.com]

Gracias por la info, Germán

                                              

                                               ¿Vos crees que la performance de Cursoradapter no es mas baja en relación a SQLexec?

 

Saludos,

 

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de Germán Fabricio Valdez
Enviado el: martes, 27 de diciembre de 2016 10:26 p. m.
Para: Comunidad de Visual Foxpro en Español <publice...@googlegroups.com>
Asunto: [vfp] Re: FoxyDB VS. SQLDATA

 

la sqldata.dll usa proveedores de ADO (oledb y odbc) de 32 bits que proporcionan los motores de bases de datos, no es necesario comprar nada

[Daniel Sánchez]

Mi experiencia es que los cursoradapters son excelente, la ventaja es que una vez que realizas la consulta con la clase cursoradapter e indicando que es una tabla actualizable y ademas indicando los campos claves, solo trabajas con tu tabla y esta se actualiza automáticamente en el motor de base de datos de origen, sin escribir una línea de código adicional, como si estuvieras trabajando con tablas locales. Realizas un insert en tu tabla local esta es reflejado en tu bd origen, eliminas un registro igual, lo importante es indicar correctamente los campos sobre los que se guiara para realizar la actualización e eliminación.

Hace unos años en el grupo mostré como usar un cursoradapter desde el entorno de datos, es muy sencillo, en mi caso no utilizo el entorno de datos si no que lo tengo en una clase y adiciono los objetos conforme lo necesito configurando según lo que necesite.

Si se fijan las clases FoxyDb y supongo la SQLData todo lo programa con instrucciones sqlexec, y para actualizar crean las estructuras insert relacionadas para enviar al servidor, todo ese trabajo ya esta echo en los cursoradapter, en si es una capa para manejo de datos, solo te enfocarías en tu capa de negocio más tu capa de usuario y ya tendrías tu aplicación a 3 capas.

Saludos

--

Daniel Sánchez Escobar
Investigación y Desarrollo
Reset Software & Sistemas
Móvil +051-949398047 RPM #948615385
Trujillo - Perú

P  Sugerimos no imprimir este e-mail a menos que sea absolutamente necesario. Protejamos el medio ambiente.

[German Fabrcio Valdez]

el tema de la programacion cliente-servidor es tratar de traer la menor cantidad de registros posibles al cliente

yo he notado en pruebas, más velocidad  en ADO que en ODBC pero trayendo 500.000 registros de un sql server 2000

en aquella epoca odbc traia mal la longitud de los campos numericos y ado  andaba perfecto , que se soluciono con la aparicion de sqlncli en sql2005 en adelante, un driver tanto para odbc como oledb

la sqldata tiene metodos que ocultan la complejidad de ADO y cursoradapter, realmente nunca accedes a ADO ni a cursoradapter con la clase

[diegod...@gmail.com]

Gracias, Daniel y German

 

                En nuestro caso, el problema es que las tablas SQL no corresponden al modelo de datos del sistema.  Por eso, cada Cursor estaría generado mediante una consulta con muchas cláusulas JOIN y UNION.

 

Supongo que en ese caso, los cursoradapter no pueden actualizar la tabla SQL automáticamente, ¿verdad?

 

Saludos,

[German Fabrcio Valdez]

la sqldata esta preparada para actualizar solo una tabla de una base de datos, puede tener agregados campos de un inner join pero deben ser excluidos de la actualizacion

pero la sqldata tiene la opcion psqlejecutar("comando") donde envias los comandos update,insert,y delete personalizados

dentro de una misma transaccion

[acmc]

Daniel,

Interesante lo que mencionas, tendrás el enlace del ejemplo que mencionas o sobre tu clase que utilizas?, me suena a algo parecido a vistas locales no?  Salu2!!

[Antonio Meza]

La primera versión dbVfp (ahora FoxyDb) usaba cursores actualizables, los problemas de usar un cursor de ese tipo es que si la conexión se pierde ya no puedes simplemente conectarte y enviar a guardar, por lo tanto debes estar siempre conectado al servidor de base de datos y ahí ya es una mala practica, desconozco como lo maneja CursorAdapter!!

Cuando desarrolle dbvfp lo que necesitaba era que fuera sencillo y con cursores actualizables así lo aparentaba, pero luego necesitaba mas liberta y aplicar buenas practicas por lo que empece a estudiar mas sobre sqlexec y lo mejore con foxydb, Entonces me di cuenta que VFP es poderoso con los cursores y aproveche esa gran ventaja para simular un cursor como si fuera un simple dbf para el lado de VFP y aprovechar las ventajas de cada servidor de base de datos con sqlexec de lado del servidor.

Otro punto muy importante y que la mayoría no conoce o no se preocupa, y es el uso adecuado de las transacciones en el servidor de base de datos, el simple hecho de enviar a consultar algo al servidor no importa por medio de que lo hagas se inicia una transacción, si las manejas automáticas entonces siempre serán de lectura-escritura, si las manejas manuales entonces te toca indicar de que tipo van hacer, este siempre detalle hace que el servidor de base de datos sea mas eficiente, por ello foxydb siempre va a manejar transacciones manuales, de solo lectura para recuperar cursores y transacciones de lectura-escritura para actualizar cursores en el servidor, parece algo simple pero es tan básico como importante. Desconozco como lo maneja CursorAdapter y SqlData, al igual que la flexibilidad de usar conexión y desconexion, en FoxyDb puedes estar editando un registro (o varios) en el cursor sin estar conectado al servidor, ya cuando se requiera actualizar los cambios entonces en ese instante te conectas, esto hace posible usar sistemas donde el servidor esta en Internet o usando conexiones Wifi.

Gracias a la OOP (Programación Orientada a Objetos) cree una clase que encapsula el código nativo de VFP para el manejo de cursores y acceso a servidores de base de datos sin tener que aprender SqlExec, TableUpdate, buffering, etc, etc, por ello es la única librería que al menos yo conozco que administra los cursores, con simples funciones, es decir obtienes el cursor de una consulta al servidor y este es administrador por FoxyDb como si fuera una tabla, creo que mas sencillo aun que usar cursoradapter y tienes mas control y buenas practicas.

Se puede trabajar con conexión permanente o conexión por acción o grupo de acciones, en mi caso siempre uso conexión por acción o grupo de acciones al servidor.

Si obtienes un cursor con multiples Join foxydb solo va a enviar a guardar los cambios de la tabla principal de esa consulta, sin necesidad de especificar los campos a excluir, y obtener el ultimo ID insertado de manera sencilla.

Y lo mas importante en foxydb se debe aplicar buenas practicas Si o Si, para obtener un mejor rendimiento en los servidores de base de datos. pues de nada sirve usar Firebird, MariaDb, etc, si al final se traen todos los registros para modificar uno o agregar nuevos, es como usar excel o tablas dbf.

P.D. El hecho de comparar no necesariamente debería terminar en decir cual es mejor y cual es peor, si me dicen que X es mejor que Y me gustaría saber y conocer en donde X es mejor para así poder mejorar Y en vez de ponerme a defender Y jajajajaja

saludos

Antonio Meza

[acmc]

Muy buena explicación Antonio!!

[mpulla]

Hola isg-alexa.

No he probado ninguna de las dos, pero he escuchado que las dos son buenas.

Mi recomendación es que aprendas que aprendas t-sql, el standar te sirve en casi todos los SGDB, pero es mejor aprovechar el potencial del SGDB, personalmente manejo Sql Server y Postgresql (la mayoría trato de resolver en SGDB con SP o Funciones), no me limito a DML standar trato de aprovechar las características que tienes cada uno, ganas en velocidad y las cosas son más fáciles, te menciono unas pocas para que veas si existen en MariaDB

CTE, CTE Recusrivas, Cross Apply (Sql Server), Lateral Join (Postgresql), Merger (Sql Server), Funciones de ventana Lag, Lead, Row_Number, Last_value, First_Value, entre otras, toda ellas muy buenas.

Hay momentos en que deseamos pasar un cursor de VFP a Sql Server o Postgresql en un solo paso puedes apoyarte en XML o JSON (tengo entendido que en Sql Server 2016 JSON ya es nativo o por lo menos un mayor soporte)

Sobre CursorAdapter es muy potente, lo utilizo con ODBC y es muy rápido, utilizo la misma tecnica que muchos abro la conexión, consulto, cierro la conexión, manipulo los datos, abro la conexión grabo y cierro sin problemas, tengo una clase que me ayuda a crearlas al vuelo, No te metas con ADO M$ lo descontinuo

La cosa más importante es cambiar la mentalidad de hacer las cosas registro por registros o dentro de un while o scan, piensa en conjunto de datos, Sql Server y Postgresql manejan el concepto de cursores, te verías tentado a usarlo ya que es muy parecido a recorrer un cursor en un scan o  while, pero hay un dicho "El mejor cursor es el que no se usa"

Como dice Antonio ten presente un uso adecuado de las transacciones.

Hay muchas cosas nuevas que tenemos que aprender y apoyo no va a faltar

Saludos.

Mauricio

[German Fabrcio Valdez]

microsoft no discontinuo el ADO (WDAC), por supuesto que le hace
propaganda al ADO.NET

y esta atada la continuidad de ADO, al ciclo de vida del windows

windows 10 muere en 2025

de todas formas yo hago sqldata (ado) y sqldata2 (odbc) ambas mediante
cursoradapter

y permiten conexion continua al server mientras esta ejecutandose el
programa , o abriendo y cerrando la conexion segun se necesite, en ambas
clases automaticamente

lamentablemente desde visual foxpro, no me deja conectarme a AZURE de
Microsoft

tambien estan optimizados los bloqueos de registro y las transacciones


El 29/12/2016 a las 0:04, 'mpulla' via Comunidad de Visual Foxpro en
Español escribió:

[diegod...@gmail.com]

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----
De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de German Fabrcio Valdez
Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.
Para: publice...@googlegroups.com
Asunto: Re: [vfp] Re: FoxyDB VS. SQLDATA

[Carlos Miguel FARIAS]

Las dos librerías son una porquería, son obsoletas

.

.

.

.

.

.

.

.

.

.

no manejan negritas ni subrayados.

.

..

.

.

.

.

.

.

.

.

Hoy no es viernes pero es el día de los inocentes 👶

Saludos: Miguel, La Pampa (RA) 

Larga Vida y Prosperidad 🖖

Que la Fuerza me acompañe, me cayó mal el tomate 🍾

El 29 de diciembre de 2016, 10:53, <diegod...@gmail.com> escribió:

Muchas gracias, Mauricio, Daniel, Antonio y German!

Valiosísima información y notable el tiempo dedicado desinteresadamente a cada respuesta.

Creo que las dos clases merecen el trabajo de probarlas por separado, y que cualquier elección será buena.

Seguramente volveré a molestarlos en enero.

Saludos y feliz 2017



-----Mensaje original-----

De: publicesvfoxpro@googlegroups.com [mailto:publicesvfoxpro@googlegroups.com] En nombre de German Fabrcio Valdez

Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.

Para: publicesvfoxpro@googlegroups.com

[Antonio Meza]

Por supuesto que si maneja Negrita y Subrayado mira:

FoxyDb

FoxyDelineateBold

jajajaja

De: publice...@googlegroups.com [mailto:publice...@googlegroups.com] En nombre de German Fabrcio Valdez

Enviado el: jueves, 29 de diciembre de 2016 1:14 a. m.

Para: publice...@googlegroups.com