Componentes adecuados para cada base de datos

[[David]]

Hola

En Delphi hay varios componentes para conectar con la base de datos . No sé si hay componentes que sirven para todas las bases de datos , por ejemplo , no sé si con ADO se puede uno conectar a interbase por ejemplo .

Pero estaria bien poner una lista de las principales bases de datos y la paleta de componentes a los que se puede conectar , por orden de preferencia .

Por ejemplo :

Paradox : BDE
Interbase : Interbase , BDE (quiero decir que para interbase usar la paleta de interbase como 1ª opción y la paleta de BDE como 2ª opción) .

Así según la experiencia de cada uno para las principales bases de datos , como SQL Server , Access , Oracle , MySQL , etc ...

[[poliburro]]

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

y eso amigo mio prácticamente todas lo soportan.


PARADOX
DBASE
MSSQL
ORACLE
MYSQL
INFORMIX
INTERBASE
FIREBIRD
DB2
ACCESS
PostGress

Ahora que lo ideal es usar OLEDB y eso lo proporcionan

MsSQl
ORACLE
INFORMIX
DB2
INTERBASE
FIREBIRD
Postgress



Yo te recomiendo el uso de ADO por sobre cualquier otra tecnologia.



adoradores de dbexpress, zeos y etc. es mi muy particular opinión

[[Caral]]

Hola
Yo trabajo con ADO, pero esto:

adoradores de dbexpress, zeos y etc.

me parece muy fuerte, ya que en realidad creo que un programador adora lo que le trae menos problemas o funciona mejor, es el caso de ado y mysql, la verdad no camina bien, si es grande la base de datos, a mi me funciona mucho mejor zeos, asi que es una cuestion de eso, que camina mejor y para que, particularmente.
Hay muchos componentes de enlace a base de datos y siguien saliendo mas, creo que lo importante es: que voy a hacer, para quien lo voy a hacer y si me caminara como quiero o no, de ai en adelante, es una decision muy particular, no creo que exista el componente ideal ya que para unos sera excelente y para otros no.
En la variedad esta la riqueza de Delphi.
Saludos

[[David]]

OLE DB , comprendo que es también ADO , cuando pones un ADO conection , pues y le das a build , en la primera pestaña dice

Microsoft OLE DB provider for ... (lo que sea) .

Esto es el OLE DB , que es tan bueno ?

Si es así empezare a utilizar más ADO ,que jamás lo utilizo , por lo menos en los ultimos tiempos .

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

Hablando siempre de componentes que trae delphi, entiendo que ADO es la mejor opción para acceder a MSSQL Server o a Access (via OLEDB), incluso para algunas Bases de Datos sencillas tipo Paradox/DBASE como forma de evitar el BDE, pero no creo que para trabajar con IB/FB sea mejor que utilizar los componentes nativos (IBExpress).
A cada cosa lo suyo.

Como última opción sí puedes utilizar ODBC (a través de ADO) para acceder a casi cualquier cosa s(iempre que tengas el driver ODBC), pero dado su rendimiento lo dejaría como última opción.

En alguna ocasión he probado ADO para acceder a Oracle y tampoco funcionaba del todo mal. Seguro que mejor que ODBC/BDE y supongo que peor que utilizando componentes de pago específicos para Oracle (entiendase DOA, por ejemplo), aunque estos ya no vienen con Delphi.

[[poliburro]]

Si y no.
Es verdad que al usar los componentes IB estas accediendo de forma nativa al motor de base de datos. Pero también es verdad que si usas OLEDB con ADO, por lo menos en la capa de conexión estas usando un modo nativo.

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

Ahora. lo que si no es para nada aconsejable y de hecho está descontinuado es el BDE.

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

Empezado por poliburro

...Pero también es verdad que si usas OLEDB con ADO, por lo menos en la capa de conexión estas usando un modo nativo.

Lo que no acabo de ver es dónde está el proveedor OLEDB para IB/FB y poder acceder así utilizando ADO de forma nativa.

Yo tengo para SQL Server, MSAccess (Jet4), Oracle,... ¿Exactamente cómo configuras tu conexión ADO para acceder a IB/FB?

[[poliburro]]

Empezado por Neftali

Lo que no acabo de ver es dónde está el proveedor OLEDB para IB/FB y poder acceder así utilizando ADO de forma nativa.

Yo tengo para SQL Server, MSAccess (Jet4), Oracle,... ¿Exactamente cómo configuras tu conexión ADO para acceder a IB/FB?

What is IBProvider?


The product is a Native OLE DB provider for access to all versions of InterBase and Firebird SQL-servers. Using IBProvider, you can create applications based on:

• All versions of Microsoft Visual Studio (5.x, 6.x, 7.x) including Microsoft Visual Studio .Net 2005 (ADO.Net 2.0).
• C++ and Delphi.
• Microsoft Office (including Microsoft Access) through the Visual Basic for Applications (VBA).
• ActiveX Scripts and Crystal Reports.
• Windows Scripting Host scenarios.
• ASP and ASP.Net for Web applications development.

Infact, you can use IBProvider to create any Windows-based applications for InterBase and Firebird.
Schemata of connection to InterBase and Firebird through IBProvider The Brief Overview of IBProvider Features

• All versions of Interbase (IB4.x, IB5.x, IB6.x, IB7.x) and Firebird (FB1.x and FB2.x.) support.
• Wide range of OLE DB data types and support for all InterBase and Firebird data types.
• Integrated data type converter.
• Support for reading & writing BLOB-fields through the streams.
• Array data type support.
• Presence of UNICODE mode, providing special support for the following code pages: UNICODE_FSS, WINXXX, DOSXXX. The mode provides automatic conversion for ordinal fields, arrays, BLOB-fields and storage-objects.
• Three-level isolation of transactions: Read Committed, Snapshot and Snapshot Table Stability.
• AutoCommit mode with user-specified isolation level.
• Biphase commit of transaction.
• Support Microsoft Transaction Server.
• Support connection pool services.
• All sets of logic and physical information schemes.
• Now you can use Interbase or Firebird as a linked Microsoft SQL Server for heterogeneous queries execution.
• Support MS Analysis Services.
• Full support of IB SQL, including a calling stored procedures and managing of transactions through SQL.
• Support of ODBC-extensions in SQL-queries.
• Named and unnamed query parameters support.
• Automatic recognition of query parameter types.
• IN-OUT parameters.
• Client Cursor Engine support.
• Server Cursor support - four the specialized modes:
  • Unidirectional access, read-only data.
  • Random access, read-only data.
  • Random access, immediate update.
  • Random access, delayed update.
  Updateable rowsets implementation:
  • Automatic and controlled modes of database updating.
  • A pool of the prepared SQL-queries for database updating.
  • Possibility to use separate transactions for reading and writing data.
  There are no size restrictions for the processing data in all the modes:
  • 64-bit access to automatically created temporary files;
  • High-performance rowset data cache.
• Support of multithreaded InterBase applications.
• Multilanguage messages support.
• Custom Data Link Pages.
• Minimal system requirements: InterBase SQL Server client (gds32.dll) should be installed... IBProvider doesn't require installation of MDAC library service components.

IBProvider represents a powerful object-oriented low-level client API for work with InterBase and Firebird. Integrating into database applications, IBProvider is capable of incurring all work on the organization of interaction with InterBase. As all the resources for work with the database are presented as COM-objects, you do not have traditional client application constraints. Programs can be split up into modules, created in different programming systems. Using scenarios written on VBScript/Jscript, you can add logic that is not realizable on the database level. OLE DB is the standard of access to the data that allows you to develop and operate databases easily.
So, development of large scalable client InterBase and Firebird applications using Microsoft development tools, and any other systems that support OLE DB, has become more accessible and easier than it was before.

[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.

[[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

[[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...

[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.

[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

[[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

[[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