tag:blogger.com,1999:blog-2369540291979930022.post1587325830420883490..comments2023-06-19T16:01:28.675+01:00Comments on The Delphi Disciple: Migration to XE3: ADO completeAnonymoushttp://www.blogger.com/profile/17816129627979839377noreply@blogger.comBlogger6125tag:blogger.com,1999:blog-2369540291979930022.post-61259427979796432202013-06-18T16:59:47.806+01:002013-06-18T16:59:47.806+01:00Hi Jason (and others who say Microsoft has depreca...Hi Jason (and others who say Microsoft has deprecated ADO etc),<br /><br /><br />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 Anonymousnoreply@blogger.comtag:blogger.com,1999:blog-2369540291979930022.post-15453744705240577662013-03-06T11:03:18.831+00:002013-03-06T11:03:18.831+00:00Just4fun:
BDE - fastest, but long since deprecated...Just4fun:<br />BDE - fastest, but long since deprecated<br />ADO - fast enough, recently deprecated<br />ODBC - slower than two others, widely embracedILnoreply@blogger.comtag:blogger.com,1999:blog-2369540291979930022.post-52818689172933683022013-03-06T07:06:18.170+00:002013-03-06T07:06:18.170+00:00Alcalde,
Thanks for your comments, I appreciate t...Alcalde,<br /><br />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.<br /><br />You make a good point about ODBC and that is the advantage of using the components we have chosen - we Anonymoushttps://www.blogger.com/profile/17816129627979839377noreply@blogger.comtag:blogger.com,1999:blog-2369540291979930022.post-42577038499022466702013-03-06T00:06:07.630+00:002013-03-06T00:06:07.630+00:00>Yes, we were well aware of the fact
>that ...>Yes, we were well aware of the fact <br />>that Microsoft have said they're <br />>deprecating ADO, but they've <br />>previously also said that about ODBC. <br /><br />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.). alcaldehttps://www.blogger.com/profile/14404682533930977783noreply@blogger.comtag:blogger.com,1999:blog-2369540291979930022.post-6131484581374402932013-03-05T12:23:38.016+00:002013-03-05T12:23:38.016+00:00Thank you Arnaud,
Yes, we were well aware of the ...Thank you Arnaud,<br /><br />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. <br /><br />It isn't ADO as a technology that I was Anonymoushttps://www.blogger.com/profile/17816129627979839377noreply@blogger.comtag:blogger.com,1999:blog-2369540291979930022.post-77460960470179089472013-03-05T12:12:14.300+00:002013-03-05T12:12:14.300+00:00ADO relies on OleDB which is officially deprecated...ADO relies on OleDB which is <a href="http://blog.synopse.info/post/2012/02/29/Microsoft-states%3A-OleDB-out-enjoy-ODBC!" rel="nofollow">officially deprecated by Microsoft, in favor to... ODBC</a>!<br /><br />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 Arnaudhttps://www.blogger.com/profile/00421394020248758254noreply@blogger.com