What is difference between ADOTable and ClientDataSet - delphi

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.

Related

Does Firebird 3 embedded server have major disadvantages?

Are there major disadvantages using the embedded Firebird 3 in a multi-user application server (Delphi Webbroker) instead of the full blown server install?
The application usually has very short transactions with low data volume.
As far as I am informed accessing one database file with multiple threads through the embedded server is not problematic but user security is not available. As the application server does the rights stuff I do not need Firebird security.
But will I loose performance or things like garbage collection?
Firebird Embedded provides all the features (except network access and authentication) that a normal Firebird server provides. However, because it is in-process, any problems that cause your application to crash, will take Firebird with it and vice versa.
Other possible downsides:
Garbage collection will - as far as I know - always use the 'cooperative' model (where the connection to find old record versions, is the one that cleans it up),
You can't use other tools to access your database remotely which may make administration harder,
You can't put your database on a separate server from your web application (think of security requirements).
Personally, I would only choose Firebird Embedded if the situation calls for it. In all other situations, I will use Firebird Server.

UniData External Data Access (EDA) synchronization

Is it a good idea to continuously use External Data Access (EDA) for synchronization of big files (let's say with 10 million records) with RDBMS. Will EDA also handle incremental updates to the source UniData file and automatically reflect those changes(CREATE, UPDATE and DELETE) to the target RDBMS system?
Also, according to the documentation, EDA supports right now MSSQL, Oracle and DB2. Is it possible to configure EDA to work for example with PostgreSQL?

BDE to ADO conversion in DELPHI 5

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.

Updates getting retained Firebird 1 with ZeosLib

Delphi Xe2 + ZeosLib 7.0.3 Stable + Firebird 1.0
I am doing updates to the several tables and data is retaining on memory. It is not reflected on the database in a way that other applications can see it.
I have tried using auto-commit only and did not work.
I have also used explicit transaction control, ZConnection.StartTransaction and ZConnection.Commit and did not work either.
I am updating data in a webserver created on delphi with Indy httpServer. I get post requests then act reading or updating the database. The connection is stateless, however it is maintained a list of client apps that are connected and an a instance of ZConnection for each client to have isolation since the requests are threaded.
Besides that I am having the problem of not saving having only one client connected and doing one request per time, no overlapping or re-entrance.
I need to hear advice on using this scenario of Firebird, What I should do to make the commit work.

Delphi SQLite3 using ZeosLib, how to share a database?

I am using Delphi 7 and ZeosLib 6.6.6 to access SQLite3 database.
What is the best practice to use shared database.
I plan to put the database file (data.db3) in a shared location.
And the Delphi application is on local desktop computer of every users.
I want to know how to manage database locking for example. Detecting if the database is being locked by certain user, things like that.
Thanks.
SQlite3 handle database sharing by default, locally on the same computer. You have nothing to do, just open the database several times on your hard drive. Of course, it does have an overhead, and locking will make it slower than access from one unique process.
But if by "in a shared location" you mean a network drive, as your question suggests, it probably won't work as expected.
Locking files over a network are not safe (at least in Windows world). See http://www.sqlite.org/cvstrac/wiki?p=SqliteNetwork
You should instead rely on a true Client/Server approach, still possible with SQLite3 on the server, and Clients accessing to it via the network. See e.g. our RESTful server using JSON and several protocols.
You can put a SQLite database on a shared network resource. According to the SQLite documentation - that is not recommended. Main reason - SQLite cannot effectively manage locking on a shared resource.
If you need multi-user access to a SQLite database, then you may consider using middleware, like DataAbstract. As a driver for Data Abstract you can use our library AnyDAC. Some articles: Using SQLite with AnyDAC and Using Data Abstract with AnyDAC. In first article check "Connecting to SQLite database from Delphi application" for usage cases, including how to setup for concurrent access.

Resources