Componentes adecuados para cada base de datos

[Neftali [Germán.Estévez]]

Empezado por poliburro

What is IBProvider?

Gracias por la "parrafada"; Esto ya lo conocía, pero pensé que hablámos de componentes que vienen con Delphi.
Si buscamos fuera, se pueden encontrar muchos más de los que seguramente no acabaríamos de hablar. Inclusive los homólogos a ADO (TBetterADODtaset, SDAC,...)

[Chocoslovaco]

Hola a todos en el foro

Creo que al final de cuentas creo que para los que estamos igual que David no hubo una respuesta que pudiese ayudarnos, es decir; seria bueno que los más experimentados (por decirlo de alguna forma) dieran su opinión sobre tal o cual componente, para poder establecer una correcta y eficaz conexión.

Saludos.

[[poliburro]]

Mi recomendación es que usen Ado.

la principal ventaja?

Ado lo pueden usar hasta en las macros de excell. jejejeje

En cambio Zeos, Ibexpress, etc etc, son solo para uso con delphi.

[[maeyanes]]

Empezado por poliburro

Mi recomendación es que usen Ado.

la principal ventaja?

Ado lo pueden usar hasta en las macros de excell. jejejeje

En cambio Zeos, Ibexpress, etc etc, son solo para uso con delphi.

Pues eso depende del tipo de aplicación...

Digo, si voy a hacer una aplicación que va a trabajar única y exclusivamente con Interbase/Firebird, prefiero mil veces las IBX (o alguna otra que se comunique directamente) a usar ADO...


Saludos...

[fedelphi]

hola a todos, mi caso es que estaba haciendo todo con el BDE en paradox, pero definitivamente opte por cambiar, por Firebir o MySQL. Estoy trabajando con Delphi 5 y mi primera prueba la hice con MySQL conectandome mediante ADO, durante los primeros pasos que di me salto un error que decia algo BoF o EoF registro actual no existe, bla,bla o algo asi. Entonces buscando encontre que es un bug de delphi 5 y ADO. Por lo que cambie por firebird conectandome con los componentes IB (supongo que son los IBx que aqui mencionan). Con esto quiero decir que todo depende de cada caso en particular(preferencias personales, acceso a documentacion, entorno, tipo de aplicacion, etc), ya que el objetivo final es trabajar lo mejor posible y con las menos complicaciones posibles. Un saludo para todos, y ojala despejen rapido sus dudas y se pongan a desarrollar sus proyectos. De paso si pueden darme una manito para
despejar mis dudas sobre las dos opciones que andan dando vuelta por mi cabeza.
Fede

[Neftali [Germán.Estévez]]

Empezado por Chocoslovaco

...Creo que al final de cuentas creo que para los que estamos igual que David no hubo una respuesta que pudiese ayudarnos...

Pues será que no has leído atentamente, porque yo creo que aquí se han dicho cosas muy útiles...

Con Ado puedes conectarte a cualquier base de datos que soporte ODBC

Ahora que lo ideal es usar OLEDB y eso lo proporcionan
MsSQl, ORACLE, INFORMIX, DB2, INTERBASE, FIREBIRD, Postgress

mysql, la verdad no camina bien, si es grande la base de datos, a mi me funciona mucho mejor zeos

...con odbc ahí si estas sobreponiendo una capa adicional a la conexión

...no es para nada aconsejable y de hecho está descontinuado es el BDE

IBProvider -> is a Native OLE DB provider for access to all versions of InterBase and Firebird SQL-servers

...para trabajar única y exclusivamente con Interbase/Firebird, prefiero mil veces las IBX

...de hecho accediendo por ODBC y por ADO dejas de poder utilizar entre otras cosas los "EVENTOS" de la base de datos con Firebird/Interbase

...él recomienda es usar ADO con OLEDB y no con ODBC

...no quiere decir que todas sean ciertas 100% ya que algunas están dentro de las opiniones/preferencias de cada uno, pero no creo que sea poca cosa...

[[poliburro]]

Empezado por Neftali

Gracias por la "parrafada"; Esto ya lo conocía, pero pensé que hablámos de componentes que vienen con Delphi.

Pues de nada :P, jajajaja, y bueno pues precisamente Ado es un set de componentes que vienen con delphi o me equivoco?




saludos

[xander]

Pues no creo que ADO sea la Panacea como se trata de plantear, de hecho accediendo por ODBC y por ADO dejas de poder utilizar entre otras cosas los "EVENTOS" de la base de datos con Firebird/Interbase porque no hay componentes en la paleta de ADO que te permita cachar los eventos que reporta la base de datos y eso mi amigo es oro puro en ambientes C/S.

No tienes modo de extraer el metadata, ni de poder hacer un respaldo de la base de datos, o hacer un sweep, Validarla, o ponerla fuera de linea. Nomas por decir algo.

[[poliburro]]

Empezado por xander

Pues no creo que ADO sea la Panacea como se trata de plantear, de hecho accediendo por ODBC y por ADO dejas de poder utilizar entre otras cosas los "EVENTOS" de la base de datos con Firebird/Interbase porque no hay componentes en la paleta de ADO que te permita cachar los eventos que reporta la base de datos y eso mi amigo es oro puro en ambientes C/S.

No tienes modo de extraer el metadata, ni de poder hacer un respaldo de la base de datos, o hacer un sweep, Validarla, o ponerla fuera de linea. Nomas por decir algo.

pues, solo es cuestion de leer la documentación . Por mencionar algo sumamente valioso en la programación Ntier, con Ado puedes generar datasets en frio con solo un par de sencillos pasos. cosa que ZEOS, BDE (no se IB como lo haga) no son capaces de hacer.

[xander]

Empezado por poliburro

pues, solo es cuestion de leer la documentación

Sinceramente lo dudo mucho, ni siquiera veo en ADO algun componente que te sirva como un medianamente funcional monitor SQL, y lo que he escuchado sobre la gente que alguna vez trato de trabajar con ODBC no ha sido nada alentador como para pensar en usar esa capa de acceso.

a que no usas un cucharón para comer la sopa?? si, claro, el cucharon sirve para mover la sopa en la olla sin importar si es sopa de habas, arroz, tortilla o frijoles, pero comer usando el cucharón ya no es tan bueno. Sobre todo porque para comer sopa de tortillas es mejor usar un tenedor.

[roman]

Aunque no deja de parecerme extraña esta defensa a ultranza de ADO por sobre todo lo demás, hay que notar que el compañero poliburro aclara desde un principio que lo que él recomienda es usar ADO con OLEDB y no con ODBC.

// Saludps

[srm]

Empezado por roman

Aunque no deja de parecerme extraña esta defensa a ultranza de ADO por sobre todo lo demás, hay que notar que el compañero poliburro aclara desde un principio que lo que él recomienda es usar ADO con OLEDB y no con ODBC.

// Saludps

Alguien puede poner un ejemplo de Connection String de mediante "Microsoft Jet 4.0 OLE DB Provider" con un BBDD de MySQL.
Host: 192.168.1.2
Usuario: prueba
Pwd: prueba

Gracias

[[poliburro]]

Empezado por xander

Sinceramente lo dudo mucho, ni siquiera veo en ADO algun componente que te sirva como un medianamente funcional monitor SQL, y lo que he escuchado sobre la gente que alguna vez trato de trabajar con ODBC no ha sido nada alentador como para pensar en usar esa capa de acceso.

Ado no es ODBC mi hermano, y ado es sumamente poderoso por ejemplo

si tienes un Sp que devuelve varios recorsets, como los manejas con IBEXPRESS?

Si necesitas manejar conexiones en frio como lo harias con IBEXPRESS?

Si requieres generar Datasets actualizables a partir de Esquemas XML, como lo harias con IBEXPRESS?


coincido en que los componentes nativos incluyen cosas específicas del motor pero insisto. Desde mi experiencia con ado y MsSql, Mysql, Oracle, Db2, Access.

Puedo decir a ciencia cierta que prefiero ADO que Zeos, Ibexpres y todo el largo etcetera, INSISTO es mi humilde y muy personal opinion.

[Nelet]

Empezado por poliburro

Si necesitas manejar conexiones en frio como lo harias con IBEXPRESS?

Por curiosidad...que hoy estoy espesito. ¿A que os referís con "manejar conexiones en frio" o "generar datasets en frio"?.


Que estamos casi en noviembre y hace un calor de la leche aquí en Valencia

[Neftali [Germán.Estévez]]

Empezado por poliburro

...y bueno pues precisamente Ado es un set de componentes que vienen con delphi o me equivoco?

ADO sí viene con Delphi, pero no el proveedor OLEDB para acceder a IB/FB a través de ADO(o al menos yo no lo he visto por ninguna parte).