For the second time in two weeks I have seen someone post a question about a project which uses (non-.NET) ADO and DataSnap (a.k.a. MIDAS, TClientDataSet) together. Don’t combine these!
ADO and DataSnap do almost the same thing. Some people have speculated that ADO was more or less a recreation of DataSnap. There is no need to combine them; putting one abstraction layer on top of another is asking for performance problems at a minimum. Choose the one you want to use and stick with it.
Don’t believe me? Look up "Using Batch Updates" in Delphi help, which does a property-by-property comparison of ADO and TClientDataSet. They omit some things, like TClientDataSet.Data corresponds to TCustomADODataSet.RecordSet, but if it exists on TClientDataSet you’re likely to find an analog on TCustomADODataSet.
{ 15 } Comments
While DataSnap/Midas is, as you sayed, an abstraction layer plus clientdataset, ADO is also an data access technologie (the native one for mssql etc). So we use datasnap/midas at the frontend and middle tear and ibx, doa, ado for data access at the database layer to support different rdbms engines. So I thing it is OK to combine ADO and DataSnap in some szenarious. I depents on why and how..
PMM
It’s OK to combine them if you don’t care about performance, memory footprint, or maintenance.
If you want to use the "native" MS-SQL OLE-DB provider with TClientDataSet, use dbExpress, which uses the OleDB interfaces without the redundancy of RecordSets.
Cary Jensen has recently stoked my imagination with using the XMLData string provided by the TClientDataSet. That combined with the "native" nature of the ADO dataset allows the advantage of a stand-alone executable that allows handling and passing of datasets when you combine these two paradigms.
Is there a way to implement any type of an XMLData bolt-on to the ADO dataset to cut out the middleman?
Terry, I haven’t tried that, but you can read an write XML *files* using TCustomADODataSet.LoadFromFile / SaveToFile. There may be a way to do it without files but I can’t name it off the top of my head. I’d suggest looking at the ADO docs on MSDN.
I decided to use DbExpress for a pet project of mine (we’re using ADO and CDS at work). DbExpress performs much better than ADO, but I’m having a lot of problems with errors and many access violations in the MS SQL DbExpress driver. Some seem to be related to multiple threads using DbExpress, some happen when I try to run invalid SQL. It just feels like this technology isn’t ready for serious use. So maybe I’ll go back to the old proven workhorse of ADO + CDS for my pet project too, unless someone’s got a better idea?
JB, if you’re going to use ADO/dbGo, you don’t need CDS. That’s the whole point of the post. That said your errors may be fixable so I’d be sure I understood the precise cause for sure and be positive there is no workaround before changing the foundations of my process.
Hi Craig,
Your post is of extremly interest for me.
This is our current setup, we are using DataSnap, we have multiple transactional data modules with ADO components (connection, queries, stored procs) on them, this transactional Data Modules are sitting off course on MTS and they are connecting to MSSQL Server 2000.
That has being our solution for a while, and it works. My question and this is a BIG question cause i’m always open to improve our current design in order to get better performance is, will you suggest dbExpress components to be used instead of the ADO ones? Notice the existance of the MTS and SQL Server 2000, will i get something better out of dbexpress?
We have Delphi 2006 and the way we design the system will allow us to quickly (kind off) move to dbExpress, BUT, we cant risk stability.
Thanks in advance.
Esteban, I have never tried using dbExpress with MTS, so I can’t comment on it. But you don’t need CDS on the client tier for what you’re doing; you can remote the RecordSets from your ADO components. It’s less critical in this case, though, since whether you choose ADO or CDS components for the client tier they’re essentially doing the same thing rather than completely duplicating each other.
When using ADO / dbGo on either the client or server tier for an n-tier app, be *very* careful with your cursor type, etc. Unlike dbExpress, which is always unidirectional and has essentially one configuration, the ADO dataset is the equivalent of TSQLDataSet, TDataSetProvider, and TClientDataSet rolled into one, so you need to configure it correctly for each tier.
Thanks for the answer Craig.
I will have to do some more reading around to see if someone has done such combination and how it worked.
Until now, all I had heard about MSSQL dbx driver is: USE ADO.
Because of it, never gave a chance to it.
And CDS is good to get abstraction from the datalayer ie, frameworks can use datasets of any data layer and not changing a line of code - ie open DBF datasets from a old BDE module, get data as unidirectional and close the beast. For migration tools, is simply perfect.
I intend to build ui all based on CDS and add inherited datamodules with the right layer for data access. If MS screw up like it had done with MDAC 2.7 (’unspecified error’, but the sql works so all try..except that rollbacks roll a successful txn arrrrrrrrrrrggggh) again, just reinplement just the dm with another layer that works…
Do you know a more exact location of where I could find the ‘property-by-property comparison of ADO and TClientDataSet’.
Tried the link and a Google search but haven’t been able to find it.
Am having some kind of syncing issue with an application that is using ADO and ClientDataSets. If I have this information it will help me to remove the CDS and update the ADO compontents.
The comparison is in the Delphi help file. Ignore the link; use the Help menu.
does ADO has something like delta property in ClientDataSet?
Sort of, web9527. You can Filter with a FilterGroupEnum of adFilterPendingRecords.
Thanks! Craig.
Post a Comment