A new year and time to make a decision about how we are going to move our ten year old codebase from Delphi 6 up to Delphi 2009. If you've followed my other posts in this "road to Delphi 2009" thread then you'll know that I hit a stumbling block when migrating a third-party component, ODBCExpress. This is a third-party database connectivity component that was well written, well documented and had good reviews and articles in Delphi Informant (which dates it a bit for those who remember that magazine).
At the time we chose it, our product was based on the Access database and we were looking to add SQL Server support, so we chose it as a good option to handle any database type. I explained this back in June 2007.
Unfortunately, the product was no longer actively developed from Delphi 2006 and despite help from its main developer to at least get it compiled into Delphi 2009, it didn't work properly thanks to all the Unicode changes.
Seeing as we bought Delphi 2009 in June 2009 and haven't migrated to it yet, a decision has been made. We are going to move all the code away from ODBCExpress, and to the dbGo ADO components provided as standard with Delphi (from Delphi 5 through to the current Delphi 2010).
Presciently, in June 2007, I also said this:
I've thought about moving to one of those bundled Delphi offerings in order to save myself the worry should ODBCExpress go tilt. But I haven't...because the database architectures offered with Delphi keep changing and I'm not sure I want to run the risk of changing everything over only to have it "deprecated" like the BDE.
Well the dbGo components are still going strong and they made the effort to Unicode-enable them for Delphi 2009, so I'm classing this as a low-risk option.
I wrote some test programs using the ODBCExpress components and then migrated it to ADO to see what conversion issues I'd have. I made notes and it wasn't as bad as I thought. I can now do everything I could do with the ODBCExpress components, even if I have had to write a function that does what a component used to do. If anything, it has been an interesting exercise in the back-end of SQL Server.
What was particularly pleasurable was doing all the work in Delphi 6 and then simply recompiling it in Delphi 2009 to see what happened. The answer: it compiled and ran just as it did in Delphi 6 (give or take a few string cast warnings in my own code which is part of the Unicode migration, and expected). Perfect.
For those who may ask why I'm not going for dbExpress instead (which is also standard with Delphi and developed by CodeGear/Embarcadero), it was a couple of things. It was initially my preferred choice but the extra DataSetProvider/ClientDataSet layer required to use it visually gave me the creeps, and I've been reading some frightening problems that people are having with it with Delphi 2010 and SQL Server. Plus the architecture of dbGo more closely matches that of ODBCExpress, facilitating the migration.
So now we have a path, a light at the end of the tunnel. It's not going to be pretty, and I know it will be tedious, but it will be another third-party component set that I can drop which, as I said in another posting in June 2007:
that the less third-party tools I can get away with using the better, purely for future-proofing purposes. If Delphi then provides that same component as standard in its next version, I'll use that one and thus reduce my dependency.
I'm now looking forward to the journey again.
7 comments:
Why not just code against ADO directly? That's I do these days, using myown "vacuum wrapper", that is an extremely "thin" VCL encapsulation, just to provide more type-safe (and IDE friendly) enums and parameter lists where there are optional params at the COM layer etc.
The encapsulation also provides a layer in which to abstract out some of the fiddly aspects of ADO, e.g. I can still use named parameters and my wrapper takes care of stored procedure call syntax variations according to the provider in use, but without dragging in a massive overhead to support TDataSet.
It means forgoing data aware controls but frankly that's no great hardship (quite the reverse imho).
Clientdataset and Provider works Great with dbgo. Well worth learning.
I have long since discovered building your own components is the preferred route over the long term.
You ramp up quickly with a 3rd party component, only to have development speed flatten as your requirements begin to conflict with those of the component.
You ramp up slowly when writing your own, but development speeds up once it is up and running and you use the methods you wrote yourself.
It also educates you to see through the hype when new components/technologies appear.
Your comments are welcome and appreciated. I fully understand your points about writing your own components or wrappers, and that would be an option if I was starting from scratch.
But what I need is a solution that I can migrate 50 projects, and 10 years worth of code, to quickly and easily. And so because these projects already use TDataSets and data-aware controls, the dbGo components offer me an effective and reasonably future-proof solution (as much as that can ever be guaranteed).
Speed is also of the essence as, while I am migrating our code base to ADO and D2009, I'm not developing new features into our software or fulfilling bespoke work, so there is a real-world aspect to how this plays out.
Actually when you compare the history of supporting database frameworks over time BorCoDero comes up pretty favourably against Microsoft.
BorCoDero has had BDE, dbGo, dbExpress, Midas/DataSnap all of which are supported in the latest Delphi version apart from the BDE which is still there for you to use, just not recommended.
Compare that to Microsoft over the same time period. It goes something like ODBC, RDO, DAO, ADO, OLEDB and lastly ADO.NET. How many of those libraries are still supported in the latest version of Visual Studio?
Nice point Lachlan. And then, of course, there are WinForms, etc.
For Microsoft databases (Access/SQLServer), there are basically two options for direct connections:
- out-of-the box: dbGo
- 3rd party: AnyDAC (by RemObjects)
AnyDAC has the advantage that it supports handle sharing across DLLs (which we needed for a client).
dbGO just works.
If you ever want to go the ClientDataSet route, you can do that on top of dbGO just as well.
--jeroen
Post a Comment