Universal Data Access
As programmers at the dawn of new millennium, our problem is one of data access. We have been using Data Access Objects (DAO) in the book both to program our database and to create new tables. But if there is a need to access data sources other than Microsoft Access, the enterprise edition of Visual Basic 6.0 provides Remote Data Objects (RDO). RDO permits Visual Basic programmers to work with relational ODBC data sources. And DAO/Jet is used when we want to work with Jet and ISAM data sources. So traditionally, if we needed to work with remote ODBC data sources we would select RDO. However, when we need to access ISAM or Jet data sources, then DAO is the clear choice. But now Microsoft is offering us a new and much more efficient approach that permits us to use a single high level, efficient programming paradigm to work with everything. It's called Universal Data Access (UDA).
Universal Data Access is Microsoft's high-performance solution to access a variety of information sources, including relational and non-relational data sources. UDA is an easy to use programming interface – it is a tool and it is language independent. In other words, UDA is really a bundle of technologies that enable us to integrate diverse data sources, relational and otherwise. These tools permit companies to create easy-to-maintain solutions, and take their pick of best of breed tools and application programs.
Universal Data Access does not require the expensive and time-consuming (and many times impractical) shuttling of data from various databases into a single data store. Also, companies are not required to commit to a single vendor's products - pretty attractive for any IS department. Universal Data Access is based on open industry specifications: it enjoys broad industry support and currently works with all major established database platforms.****
The way to employ UDA is by using ActiveX Data Objects. You can see that by using ADO, we can access any data either by using tried and true ODBC or an OLE DB provider:
.gif)
So you can see that our Visual Basic 6.0 application can use DAO as we have been doing up till now. DAO can access Jet directly as we have been doing. This gives us the interface into Access, Paradox, dBase, Excel, FoxPro, Lotus 1-2-3, and text files. We can also use ODBC to talk to any SQL compliant data source. This can be accomplished either through Jet, or ODBCDirect that bypasses the Jet engine. But consider the multitude of steps that must be gone through under the hood.
Now, by using ADO, we can simply use the OLE DB provider for the specific data source and voila! - we have connected. However, we can still employ the OLE DB provider for ODBC to use ADO for communicating with any ODBC sources. So using ADO, we get everything we got with DAO, and more. And, it is actually easier to use. Life is good.