DAO and Jet database engine

DAO can access both local and remote databases. Here, local and remote are not geographically defined concepts, they are two logical concepts. The local database can be on the local computer (physical) or not on the local computer, and the remote computer is not limited to remote computers (physical).
A local database is a database that is accessed through the file system, either on the local computer or on the network, which is operated directly by the application. The remote database can only be manipulated by the DBMS, and the application accesses it through the DBMS, resulting in the Client/server architecture, the client side of the application, and the server side of the DBMS.
Microsoft Jet is a database engine used by Microsoft Access and Visual Basic. Before the DAO3.1 version, DAO was defined as "the programming interface of the Microsoft jet engine", which means that DAO and jet are almost synonymous in history. DAO access to the database is done through the Microsoft Jet database engine. Of course, the two concepts are different in meaning, and jet cannot be used directly, and only through DAO or access can you use Jet directly.
However, DAO3.1 added an important feature, which is ODBCDirect access. ODBCDirect enables DAO to bypass the jet engine and access ODBC data sources directly. With this feature, DAO is no longer bound to jet, and DAO is still inextricably linked to jet. Generally speaking, if the application uses a local database, then DAO typically accesses the database via jet, whereas if a remote database is used, then DAO accesses the database through ODBCDirect.
Jet is driven by SQL, but this SQL may not be quite the same as the usual implementations. In this case, there may be benefits, and there may be disadvantages. You must consider this difference when you use DAO to access a database. Because jet's SQL runs and some standard SQL run performance varies greatly. Consider the following SQL statement:
SELECT * from Student,teacher
WHERE Student.course_no=teacher.course_no
When this SQL statement is executed in SQL Server, SQL Server automatically connects the student table and the teacher table in an internal way, using the value of the Course_no field of the Student table to index the teacher table, so Every time a Student record is read, only one teacher record is read, and the execution of the entire statement reads 2*count (Student) records altogether.
However, this same statement, which is executed by DAO and Jet, is a Cartesian connection of two tables and then filters out records of unqualified conditions. As a result, every Student record must read all Teacher records, that is, Count (Teacher) Teacher Records, and the execution of the entire statement reads the COUNT (Student) *count (Teacher) record. If the data on the two tables were large, the execution speed of the statement would be intolerable.