If you've been following this (often tortuous) path of how we are going to migrate our 14 year old software from Delphi 6 to XE3, you'll know that our only real stumbling block was the fact we were using the now defunct ODBCExpress database component set. We needed to move to a different tool that was supported by XE3, and so we finally decided upon the dbGo ADO components that have been native with Delphi since Delphi 5.
It is with great satisfaction that I can report we have now moved all of the standard code over to the ADO components. There are still some bespoke utilities that we will come to later, but for now the standard software is up and running using ADO. It took us a little over two weeks of solid work to code out the old component set, and this was all done in Delphi 6 so that we could get ourselves to a point where, in theory, everything was working the same as before.
I'm delighted with the speed improvement we've seen in database access. I'm not sure whether this is because ADO is an improvement over ODBC, or the drivers are better, or whether the ADO components are more effective than the ODBCExpress components were. Probably a bit of everything.
It's kind of funny timing that just as we finished this refactoring, Embarcadero announced the purchase of AnyDac (now called FireDac). A few years ago when I first blogged about needing to move away from ODBCExpress, a few correspondents recommended AnyDac. I've heard nothing but good things about it, but ultimately I wanted to get away from a non-native third-party component set which is why we opted for dbGo. I'm pleased with this decision still, but I certainly would have given AnyDac a closer look had I known that it would become standard issue by the time we got to XE3.
I'd like to take the opportunity to thank my colleague Andrew for his collaboration on this task. I've been putting this off for a while now but having another pair of (safe) hands has given us the confidence to go for it, and Andrew has effortlessly ploughed through the same tedium as I have in order to get us to where we need to go.
So now, the next step is to open the code in XE3 and work through the Unicode warnings. I'll keep you posted.
6 comments:
ADO relies on OleDB which is officially deprecated by Microsoft, in favor to... ODBC!
IMHO directly rely on ODBC may be a good idea, instead of using ADO over ODBC. In this case you will have ADO <-> OleDB <-> ODBC <-> DB client layers... Perhaps not the more straightful combinaison.
Of course, having your legacy code work as expected is just the main fact! Congrats!
Thank you Arnaud,
Yes, we were well aware of the fact that Microsoft have said they're deprecating ADO, but they've previously also said that about ODBC. Given the prevelance of both, I suspect they'll be supported for a long time yet. And as you say, if OLEDB drivers stop being produced, we can fall back on ODBC.
It isn't ADO as a technology that I was intetested in, it was the dbGo ADO component set itself. It could have been anything, including dbExpress, had that not required extra work for bi-directional datasets.
>Yes, we were well aware of the fact
>that Microsoft have said they're
>deprecating ADO, but they've
>previously also said that about ODBC.
I've seen a lot of people lately use the example that at one time in its history Microsoft said/did X to disregard when Microsoft says about Y without taking context into account (.Net/WinRT, etc.). Microsoft left ODBC because of "embrace, extend, extinguish". However, the world has changed and they now need to interoperate - multiplatform has arrived, and we're not going back to monopolistic single platform for the foreseeable future. Thus what Microsoft once said about ODBC is irrelevant. It's a standard, and MS has to comply with standards now... period.
Going with ADO not only has the drawback of relying on deprecated technology, but it also locks you into the Windows platform, something else which looks to become less prevalent as time goes on. Given that you're getting a chance to revisit old software, personally I'd have done as much as possible to remove vendor lock-in.
Alcalde,
Thanks for your comments, I appreciate the discussion. As I said before, it isn't ADO as such that I'm interested in but a component set I can rely on as stable and well supported. I've used Delphi since D1 and the dbGo set is as good as I've seen.
You make a good point about ODBC and that is the advantage of using the components we have chosen - we can still use ODBC drivers if ADO drivers no longer are available.
However, just because it is old technology doesn't mean it's bad tech. We've been really pleased with the performance improvements and its stability.
If you read back on previous posts you'll see that I've generally always got it right when predicting which technologies will stick and which won't. .Net is my classic example: I didn't follow the sheep and stuck with native development, which is still one of the best decisions I ever made.
We didn't look elsewhere other than Delphi because we have 14 years of code which I'm not prepared to rewrite. Even if I was, I'd still select Delphi because I genuinely believe it is still one of the best development environments for Enterprise Windows applications that is available. I'd choose it every time.
Finally, vendor lock in is not an issue. We write Windows software for clients who have huge Windows infrastructure. We also write web software but do that outside of Delphi, although I will almost certainly use the next Delphi release to write iOS software.
Just4fun:
BDE - fastest, but long since deprecated
ADO - fast enough, recently deprecated
ODBC - slower than two others, widely embraced
Hi Jason (and others who say Microsoft has deprecated ADO etc),
Microsoft has not deprecated or made obsolete ADO or the OLEDB architectures (the COM-based API for accessing relational databases and other sources). They have only deprecated SQL Server OLEDB Provider called SQLOLEDB. Microsoft will continue supporting the OLEDB architecture for SQL Server through the Native client OLEDB provider. Does that make sense? :-)
Here is the link from MSDN regarding the deprecation which contains a full list of components that use MDAC-OLEDB which Microsoft maintained previously but will not do so going forward:
http://msdn.microsoft.com/en-us/library/ms810810.aspx#bkmk_DepMDAC_WDACComps
Also note that Microsoft ADO is an IDispatch-based COM wrapper of their famous OLE DB C++ SDK. They made ADO for Visual Basic developers who couldn't use OLE DB directly. As Delphi developers who swim easily in the COM pond, we found this mighty convenient. :-)
I doubt Microsoft will ever deprecate or obsolete the ADO/OLEDB containers. It's a rock-solid framework and many third-party database vendors continue to support it. Many of course do this by exposing their native drivers through COM interfaces.
ADO is NOT deprecated, only some *providers* which use the framework.
Kind regards
AK
Post a Comment