Jamie L. Mitchell wrote: > When I started programming about 15 years ago, the conventional wisdom > was to use middleware that would let you connect to different > databases without changing your code - ODBC comes to mind. Nowadays, > ADO seems to be the answer. However, is the conventional wisdom still > the way to go? > > My application is currently scheduled to work with MS Access type MDB > files and MS SQL Server. Therefore, I have been developing it using > ADO; that means, in Delphi 2005, using the dbGo components. > > I am wondering if there is a better solution out there? I am thinking > that I might like to move to Oracle or SQL Anywhere, or any other DBMS > that might be in use. Is ADO my best solution? I don't mind minor > mods to the source code but I really don't want completely separate > applications. > > I know this might be a religious question...I am not trying to bring > on a war, just wondering what you out there think on the subject. > > Thanks for playing... > jamie
IMO, ODBC is still the way to go. But I don't use Delphi very often (I'm a C++ guy). If for no other reason, you have a decent chance of being able to port your applications to other platforms besides Windows (e.g. Mac OSX) with minimal effort. Every major RDBMS vendor has ODBC drivers for multiple platforms. It also depends on the application. If you need performance, nothing is going to be faster than the database's own raw API interface. The downside is that it ties your application to a single RDBMS. The upside is you can run a few hundred-thousand queries in a short amount of time. ODBC/ADO/etc. introduces a few layers of management between your app. and the raw APIs. For the most part, this is fine. But it really depends on what you plan on doing. -- Thomas Hruska CubicleSoft President Ph: 517-803-4197 *NEW* VerifyMyPC 2.5 Change tracking and management tool. Reduce tech. support times from 2 hours to 5 minutes. http://www.CubicleSoft.com/VerifyMyPC/
