ADO components in delphi - delphi

I am currently using BDE components to connect to a database in Delphi 5 professional version. My problem is that BDE components need BDE Administator to run the application on another machine. So I am planning to buy a new version of Delphi which contains ADO components.
Question: Are ADO components also having issues like the BDE? Do ADO components need any specific setup to run applications on another machine?
Thanks for the help.

All the components have issues in some point, in the case of ADO is very stable, but you can have some specific problems with the providers (like the infamous not support for blob fields in ORACLE using the Microsoft provider) but certainly is more recommendable use ADO instead of the deprecated BDE. About the dependencies, ADO uses providers to connect to the RDBMS, most of them are installed by MDAC (Microsoft Data Access Components) which is included in most of the Windows versions. So in most cases you will not need install any addtional component, at least which you want use a provider not inluded in MDAC like MySql, Firebird or others.

Sounds like if you posted two times the (almost) same question... with more focus on ADO this time.
As was written in the previous question, if you attempt to connect to an Oracle database using ADO or OleDB, you'll find out that all OleDB providers are buggy for handling Oracle BLOBs: Microsoft's version just do not handle them, and Oracle's version will randomly return null for 1/4 of rows... So IMHO ADO or OleDB are not a serious option for accessing Oracle database. :(
And if your purpose is to get rid of the BDE installation, you'll find out that the Oracle's OleDB provider is quite huge and that the BDE is much light and better... A standard Oracle's client installation containing the OleDB/ADO provider (which is not installed in the "Light" version of the Oracle's clients), needs a .zip setup of about 660 MB...
On real database data, I found out our Open Source direct access to Oracle to be 2 to 10 times faster than the OleDB provider, without the need to install this provider (nor the BDE). You can even use the Oracle Instant Client provided by Oracle which allows you to run your applications without installing the standard (huge) Oracle client or having an ORACLE_HOME. Just deliver the dll files in the same directory than your application, and it will work.
Of course, this is full Open Source, and works from Delphi 5 up to XE. So when your project may upgrade to a newer Delphi version, it will work. You are not tied to non-Unicode Delphi 5-Delphi 7 version of Oracle components, as you can found on Torry's, e.g. but those components may help you get rid of the BDE installation for an existing project.
If you don't use BLOBs in your database, you can use ADO. In this case, my advice is to read this post, and use TADODataset, which is available in Delphi 5.

Ok Naren, since you are on Oracle you can use this Oracle driver DOA. We use it exclusively in our Delphi projects.
All our Delphi projects are on Delphi 7 but we are converting all of it to Delphi XE now. When using DOA you do need to install the Oracle client libraries on the client machine. The upside is speed and Oracle support, so the DOA drivers don't need to work on the most common command set like ADO needs to, so the Oracle support is brilliant.

Related

Using ADO to connect Paradox database on Delphi 10.2

Currently I have an old Delphi project using BDE to connect to Paradox.
We want to investigate whether ADO can be used to replace the BDE but still use Paradox for Delphi version 10.2 Tokyo.
So please advise me that Delphi 10.2 supports Paradox Database? If so please give advice on replacing the BDE to ADO?
Thanks & Best regard
A Microsoft ODBC driver for Paradox databases comes with Windows, so you can certainly connect to Paradox tables using ADO and ODBC. See the 32- and 64-bit ODBC administration apps under Control Panel | Administrative Tools, and in particular its Drivers tab.
To create a simple Paradox + ADO app:
Use Windows' ODBC wizard to create a system- or file-DSN that uses the MS ODBC Driver for ODBC to connect to the Paradox table.
In your Delphi app, use a TAdoConnection to use e.g. the OLE DB provider for ODBC to use the DSN and a TAdoQuery to do a SELECT * from the P'Dox table.
See my answer here
BDE to ADO conversion in DELPHI 5
for a way of converting from BDE to ADO to access Paradox tables. Btw, once you have access to your Paradox data via ADO, it is straightforward to replace Paradox with a proper, robust RDBMS.
Recent versions of Dephi, including Tokyo, come with a very capable alternative DB-access library called FireDAC, but:
It has a much steeper learning curve than ADO.
Its author no longer works for Embarcadero, so with their numerous other lay-offs, FireDAC may become an "evolutionary dead-end."
Being from Embarcadero, it does not have the "safety in numbers" that comes with using MS's tried and tested ADO.

How can I use embedded Firebird in my Delphi application

My Delphi XE3 application used Interbase components to connect to a Firebird 2.5
SuperServer.
I started a new project to isolate the problem, and tried to connect to my software database. The results follows.
1 - I can connect to the database using TIBDatabase normally.
and I want to deploy it to use embedded Firebird my question is:
can I use Interbase components to connect to a embedded Firebird?
if yes then how can i do it?
if not then is there any free Firebird components?
While Interbase and Firebird are sill almost compatible API-wise, I recall some have reported having problems when using IB components (which come with Delphi) when connectiong to Firebird. These components are officially for Interbase only and thus you can be sure that over time the situation will get worse (more incompatible), not better. So I would recommend using components which officially support Firebird. I personally use UIB which is free, but there is others as well (both free and commercial).
can I use Interbase components to connect to a embedded Firebird?
By default you can use Interbase components to use Firebird.
if yes then how can i do it?
You must change the name of firebird client library, in common word.
In dbExpress and Firebird server edition => use fbClient.dll and
dbxFb.dll in client side of program.
In dbExpress and Firebird embedded edition => change name of
fbEmbed.dll to fbClient.dll and use dbxFb.dll in client side of
program(fbClient.dll and dbxFb.dll).
With IbExpress and and Firebird server edition => change name of
fbClient.dll to gds32.dll.
In addition, Daniel Magine writed an article about Firebird and dbExpress.
http://www.embarcadero.com/rad-in-action/database
if not then is there any free Firebird components?
You can use ZEOS.
UPDATE
In Firebird 3:
When does not contain a network protocol but just the database name, the Remote provider rejects it and the Engine12 provider comes to the fore and tries to open the named database file. If it succeeds, we get an embedded connection to the database.

Paradox to Delphi

I have a legacy Paradox application that has been running successfully for almost 20 years using the Borland Database Engine. Data is entered into the main program by many different order takers, who then daily put the data onto a memory stick for use by laptops in many service trucks, which also use Paradox.
I just finished rewriting the used-to-be Paradox program that runs on the laptops, using Delphi XE2 Professional and TClientDataSet (briefcase model).
Now I need to upgrade the main application to a client-server model, using a Firebird server. The question is, what is the best approach, since I don't have the Enterprise Edition. I see quite a few different 3rd party tools available, or would the tools provided in the Professional Edition be sufficient?
The tools provided in the Professional version should be fine to work with . I am assuming , you have used BDE components like TTable , TQuery etc for accessing the Paradox database . You could use the same via ODBC connection ... Best solution will be to move away from using the BDE components to ADO / other components...
http://edn.embarcadero.com/article/37538 provides driver information for Firebird

Rad Studio Delphi XE and PostgreSQL

I'm starting a new project, and this must be done in Delphi, so we get Rad Studio XE (not XE2). I have never wrote code in Delphi, I'm a C#.NET-MSSQL experienced programmer, that's why this project is exciting.
For DB, we cannot afford MSSQL, but the Express Edition is not leaved. So, we choose PostgreSQL, we have very excellent references about it. And I found it quite interesting.
But here comes the problem, the provider for the connection. I began research for this problem, and I found many options, there are some products with commercial license (AnyDac, and others). But we can't afford them. Then I found Zeoslib. Maybe it is what we're looking for, however, I can't find it and install it for XE. In the sourceforge portal, the latest version (it's an alpha), only works until Delphi14 (XE is Delphi15).
I've read too, that it requires to be compiled for the install (I need a step by step for dummies manual :D). But, this makes me doubt. How it will be deployed on the client. Is it a dll?
The project is a desktop application which connects to a server (DBMS), using CRUD statements, maybe some sprocs, ans that's all. Of course there will be more than 1 client. Just reading, updating deleting, etc..., but not at the same time, so traffic, concurrency is not a big problem.
In NET, I use the sqlclient namespace create connections, commands and that's all. I've found in Delphi the TSQL, TADO, and other objects like that. So it will be not hard at all.
So we're planning to use MSSQL Express instead.
But before that:
Is there another option to connect my RAD XE app with Postgres?
If someone knows how to enable zeoslib, can u tell me?
How is zeoslib distributed with my app in many PC's?
or
Is MSSQL Express a good choice for this project? (It's not big after all)
After reading, MySQL uses zeoslib too, and of course, the commercial providers. That's why we discarded it, among other reasons.
A component library, like ZeosLib or AnyDAC, requires to compile it into binary packages (BPL) to install into RAD Studio IDE. A libray itself may be either statically linked into EXE (nothing from library to deploy), or EXE may be built with run-time packages (you need to deploy library run-time packages). Additionally you will need to deploy libpq.dll - PostgreSQL client software.
If you know SQL Server, then use SQL Server Express edition. And probably stay with dbGo (ADO) components. PostgreSQL is quite different from SQL Server in many aspects, so you will need to spend the time to learn PostgreSQL. Which will be far more expensive than commercial libraries.
Zeos trunk works fine with Delphi XE. Don't let the "trunk" bit scare you. The mutation count is not that high.

Is there no SERVER NAME Parameter for BDE in Delphi 2010?

We are migrating a pretty big application crafted in Delphi 5 (still getting customers using this old versions) that uses BDE to connect to a SQL Server. The decided path to migrating is first Delphi 5 to Delphi 2010, then BDE to dbExpress (or dbGO, still undecided).
The problem is that BDE in Delphi 2010 doen't seems to have SERVER NAME parameter! (the one you need to set the host to connect to) and it neither seems to have a replace for that.
I've tried to force it in the strings of parameters unsuccesfuly. I still can not believe this, but maybe I'm missing something bad.
BDE support for SQL Links was removed from the BDE. SQL Server in the BDE was using SQL Links.
The announcement was made in 2002 in this article:
http://edn.embarcadero.com/article/28688
If you copy the old BDE files over the new ones in Program Files\Common files\Borland shared\BDE, you will have access again to SQL servers through BDE. I have done a quick test, and could access my Firebird 2.1 in Delphi 2010 IDE without problem. I still will have to test my application, which was Delphi 6. So I can't give a final conclusion, but it looks OK. If it is wise to continue with BDE maybe questionnable, but at least basically it still works.

Resources