I have an application in my company. I want to convert it from BDE to ADO Connection.
I searched almost everywhere, I did not find any good answer.
The AIM IS
Convert that BDE connection to ADO connection but we need to use TQuery component to fetch data from database.
So, it will look like we are using BDE but internally it uses ADO Connection.
So, please answer this question you cant imagine, how thankful i will be.
... if somehow we can set the database Alias to ADO connection ...
Just take a look at the source code of Delphi's BDE and ADO support (in e.g. DBTables.Pas and ADOInt.Pas + ADODB.Pas and you will soon see that they are as different as chalk and cheese.
You have no hope of e.g. using a TAdoConnection via the BDE from a Delphi app.
What you could do is do move your data to an ADO database (e.g. MS Sql Server) and then create a) a System DSN to connect to the ADO db via ODBC and then b) set up a BDE Alias that uses the BDE alias and c) change your existing BDE app to use the new alias instead of the one it currently uses. That way, you can continue using your existing app to access the ADO version of the data via TTable, TQuery etc and develop a parallel TAdo-component based equivalent at your leisure.
You could easily try this out using the traditional Delphi MastApp or "Fish Facts" demo application and data. Getting your existing BDE app to access an ADO-compatible copy of your data via an ODBC alias should not be more than a day's work even if you have never done it before. Actually converting your BDE app to ADO would likely take rather longer, though.
There are countless examples of different ways of copying BDE (e.g. Paradox) data to ADO data on the internet. Try looking at a few.
Related
unfortunately i have to work with ancient piece of software, that uses paradox tables.
The following code gives me exception:
fdcMainPX->TxOptions->AutoCommit=false;
fdcMainPX->StartTransaction(); <---
"Project xxx raised exception class EFDException with message '[FireDAC][Phys][ODBC]-303. Capability is not supported'"
It appears, that windows odbc driver for paradox doesn't support transactions. I suppose that ole jet engine allows transactions with paradox but i'd rather use Firedac over ADO or BDE.
How to set up connection with firedac to use MS Ole db ?
Maybe there is another way?
I am using C++ Builder XE6 Pro with Firedac
Paradox DBMS doesn't seem to be capable of transactions at all (maybe its new version, part of the Corel product is, but that doesn't seem to be your case).
However, if you just want to keep consistency of certain data batches in a single connection session, you can use cached updates.
Is using a dbExpress database faster/better/less programming than ADO connection and Access db for this instance?
Application will not be consistently reading / writing to DB
DB size will be pretty small (1000-2000 rows) (5 columns)
DB will be stored / moved with the portable application
DB will talk to app only via a local connection (no computer on a different network will connect to database)
I have never used dbExpress and only other db I have ever used was a MYSQL when programming a Website. Thanks
Glen
There is no dbExpress database. dbExpress is the name of the database components in Delphi.
Using the dbExpress components, you can connect to a target database server (SQL Server, Oracle, MySQL, etc.) using the database system's native protocol.
One of the advantages of connecting natively, presumably, is performance because you avoid the ADO middleware.
A second advantage is that you're not tied to running on Windows, since ADO is a Microsoft product. You could use the dbExpress components in a FireMonkey application and have a cross platform application.
There are some restrictions with the use of the dbExpress components unless you have the Enterprise or greater version of Delphi XE 2.
Professional includes (note the "local"):
dbExpress local database connectivity to InterBase® and MySQL
Enterprise includes:
Database server connectivity to InterBase, Firebird, MySQL, Microsoft
SQL Server, Oracle, DB2, Informix, Sybase ASE, SQL Anywhere, and ODBC
There are third party native database components available (often much cheaper than the cost difference between Professional and Enterprise).
As far as programming goes, I find that using native components is slightly easier, since you don't need to create an ADO connection string, but connection strings are also easily found on the Internet for major database providers.
I'm in the process of converting a Paradox database application written in Delphi to use SQL Server 2008 R2. We are using the UNIDAC components from Devart to access the database/tables. However, I am finding the performance rather slow. For example, in the Paradox version it is more or less instant when it opens up a table (Using TTable) with 100,000 records, but the SQL Server (Using TUniTable) take approximately 2 seconds. Now I know this doesn't seem a lot but there are 10 TUniTable datasets which open up on form creation, all of which contain around the same number of records, so at present it is taking just under 20 seconds to open them all. Does anyone have any performance tips?
I'm using Delphi 2007
IMHO, UniDAC TUniTable is just a wrapper of TUniQuery. TUniTable open may lead to fetching all records on SQL Server. Not sure how, but try to change SQL Server cursor type and/or location.
If it is not late, then consider to use AnyDAC and TADTable. It uses "Live Data Window" technology, which allows to open and browse through the large tables without significant delays, eg Open and Last calls will be always fast. We migrated few BDE applications to AnyDAC and Firebird, TADTable works really great.
What is the difference between ADOTable and ClientDataSet?
Both components are capable of performing Batch Update, why add the extra overhead of having 2 additional components like ClientDataSet and DataSetProvider.
The main difference is that ClientDataSet can operate without a connection to external database. You can use it as in-memory table or load it's contents from file.
In combination with DataSetProvider it is frequently used to overcome limits of unidirectional datasets and as a cache.
A ClientDataSet is an in-memory dataset, which has a lot of usefull additional functionallities.
One big advantage compared to Interbase/Firebird tables and queries is, that you don't need to keep a transaction alive, e.g. as long as you display the data in a grid.
Have a look at this article:
A ClientDataSet in Every Database Application
Client dataset is a generic implementation that works regardless of the underlying db access library. It can work (through the provider) with any TCustomDataset descendant, be it a dbExpress dataset, a BDE one, an ADO one, or any of the many libraries available for Delphi to allow for direct database access using the native client (i.e. ODAC, Direct Oracle Access, ecc. ecc.)
It can also work in a multi-tier mode where the data access dataset and provider are in a remote server application and the TClientDataset is in the client application, allowing for "thin client" deployment which doesn't require database clients or data access library like ADO installed on the client (the required midas.dll code can be linked to the application when using recent versions of Delphi, anyway only the midas.dll is required otherwise).
On top of that it can be used as an in-memory table able to store data in a local file. It allows for the "briefcase" model also, where a thin client can still work when not connected to the database, and then "sync" when a connection becomes available. That's was more useful in the past, when wireless access was not common.
As you can see, TClientDataset offers a lot more of a TADODataset.
The most important difference I can think of is resolving update conflicts. In fact, TClientDataSet exposes the handy ReconcileErrorForm dialog, which wraps up the process of showing the user the old and new records and allows them to specify what action to take, while with TADOTable for instance, you're basically on your own.
I'm attempting to fix some problems with some old VB6 code for a client, and the previous programmer used Activex Data Object 2.7 stored procedures. After a recent computer failure and reimage, none of the buttons that use stored procedures in the application currently work.
So, my question is where can these procedures be stored?
Thanks
Stored procedure are on the database. Unless the database was on the local machine, there are only a few things of which I can think that could have been broken/reset by a re-image.
These are all used to remap computer name references.
HOSTS
DSN
SQL Aliases