Analysis of a common database operation error (5)

Previously I mentioned the existence of OLE-DB, ADO and ODBC technology, so a very natural problem is, under what circumstances the use of what technology, please refer to the following introduction:

When should I use OLE-DB, ADO or ODBC

It is not easy to determine which technology should be used when accessing data. A public utility may be required to process multiple database types. Some data may appear on the local hard drive, some on the network, and some on the host. This option is even more difficult for products installed on devices. For example, the expected ODBC support level may depend on the installed Microsoft Office version, because this product does not provide ODBC support. You will also find that the ADO class provides more objects and methods than the ODBC class. Ado can provide some features that are absolutely required in the program, for example, you will find that both OLE-DB and ADO support dfx_currency, however, ODBC does not have the corresponding feature, but you must make some effort to master them.
Note that one reason for using ADO instead of ODBC is that ADO provides more objects and methods than ODBC.
When selecting a OLE-DB or ODBC, there are several general rules. Since ADO is actually just the packaging of the OLE-DB, these rules also apply to it. Below are some basic principles that can be used to help you decide whether to choose OLE-DB or ODBC.
Non-ole EnvironmentIf you want to access a database that supports ODBC and the database does not support Ole, ODBC is the best choice.
Non-SQL EnvironmentODBC is outstanding in SQL processing. When dealing with non-SQL databases, OLE-DB has a very obvious advantage.
Ole EnvironmentFor servers that support Ole, selecting OLE-DB or ODBC may be a half of what you want. If there is an ODBC driver available, it is a good idea to use ODBC; otherwise, only the OLE-DB is selected.
Required interoperabilityIf you need database components that are interoperable, select ole-DB.
Other problems are often composite problems, or at least they lose the convenient rules that can be used to distinguish the two technologies. For example, some features are shared by ADO and ODBC. One feature is that visual C ++ allows you to directly access any technology. This means that you can fully access every feature provided by ADO and ODBC (yes, this is really good, but it also has a defect, because when talking about access, it cannot be said that one technology is obviously better than the other ).
If you make a wrong decision, some familiar technologies will actually help you transfer the application from ODBC to ADO, or the opposite direction. Both technologies rely on database objects to manage the basic DBMS, while record set objects contain query results for DBMS. In addition, both ODBC and ADO use databases and record set objects with similar members. Even if you want to make some changes to the class and member names, you will still find that the ODBC and ADO programming code is very similar.
Both ODBC and ADO rely onExternal driverTo complete the task. However, you can alsoMicrosoft JetEngine for additional help. How does this additional support make programming easier? Consider where to execute external connections to two databases that depend on different engines. In ODBC, all required settings must be manually executed. Using ADO means that the Microsoft Jet Engine will execute these settings for you. Unfortunately, letting ADO do this means that it will lose the control level and some flexibility, and that's why you wanted to use C ++ to get data from the very beginning.
Note that ODBC and ADO have similar features, such as record sets and database objects, although MFC uses these objects in completely different ways.
In one place, ADO is definitely not used. If you want to access 16-bit data, you cannot use ADO. ODBC is required no matter what you think. However, almost no one is still using a 16-bit database. Most new projects use 32-bit interfaces, which means there is a choice. The old project already has a data access method for embedded code, so you do not have to make a decision here.
One disadvantage of ODBC is that transactions cannot be tracked as before using ADO. When using ADO with the Microsoft Jet Engine, you should be supported at the transaction work zone level. ODBC only supports database-level transactions, which means that transactions can be tracked from several different workspaces (which makes debugging very difficult and may lead to other types of problems ).
During annotation processing of ODBC databases, ADO provides database-level support, which is the same as that provided by ODBC. Unless you use the Microsoft Jet Engine, you will not be given the benefit of working area-level transaction support.

Pay attention to some of the keywords deliberately expressed.Microsoft Jet"Engine" makes work easier and more dependent on Microsoft.

Finally, we need to clarify several concepts:

Ole db is a technical standard designed to provide a unified data access interface. The "data" mentioned here is not only the data in standard relational databases, it also includes mail data, Web text or graphics, directory services, and IMS and VSAM data in the host system. The core content of the ole db standard requires that these various data storage (datastore) provide the same access interface, so that the data users (applications) you can access various data in the same way without considering the specific storage location, format, or type of data.

Microsoft's Ole (current Active X), COM (Component Object Model) and DCOM (Distributed Component Object Model) technologies, what are these, continue to find information ......