Data | Data source I am a beginner of ASP, a bit deeper, I'm puzzled by the connection to the database, and I often see that there are two ways to use the same Microsoft Access database, or three or even four of connections, which I don't understand the most:
<%
Set conn=server.createobject ("ADODB. Connection ")
Conn. Open "Provider=Microsoft.Jet.OLEDB.4.0; Data source=databasename; "
%>
<%
Set conn=server.createobject ("ADODB. Connection ")
Conn. Open "Dbq=databasename; Driver=microsoft Access Driver (*. MDB); "
%>
Why is that so? With such a problem, I began to systematically look at the problem of data source connectivity. What made me realize was that Xmxoxo had given us an ADO structure diagram and that I used the OLE DB data Connection file (. udl) file to create a data source connection.
Structure diagram of ADO:
Now I'll talk about my general view of the data source connection.
The first thing to be sure of is this ADO diagram, the pattern of ADO is that all data sources must be accessed through OLE DB interfaces, that is, ADO expects all data sources to provide drivers for OLE DB interfaces.
As we all know, all of the database management systems we use today--dbms can actually exchange visits through ODBC, because ODBC provides a variety of data sources to drive. However, the unified interface of ADO accessing the data source is an OLE DB interface, so that although more and more database vendors are beginning to provide OLE DB interfaces, such as SQL Server, Oracle, and Microsoft Access (Microsoft Jet Database engine), and so on, but there are still some data sources that are not available in this way and still need to be provided to OLE DB with the help of ODBC drivers. In this way, OLE DB defines an interface that is embedded with ODBC-driven, like an ODBC driver plugged into an OLE DB model socket like other database-driven providers. The name of the ODBC interface (OLE DB provider) is the Microsoft OLE DB Provider for ODBC drivers, which is the default provider for ADO. Keyword provider value is MSDASQL, can omit not write, so we in the establishment of data source connection, did not see provider words, that means, is certainly ODBC provided driver.
What do you think? Two nouns that have puzzled me for a long time OLE DB and ODBC I finally saw it clearly.
In fact, simply put, these two things cannot be equated because they are not a category. ODBC is a benevolent lord, a provider of drivers for a variety of data sources, and OLE DB is a dictator, and it wants all data sources to yield to it, providing a driver that conforms to its standards.
Next we use practice to prove that our ODBC is really controlled by OLE DB.
It's usually written in a book. A database usually has a "DSN method and a non-DSN method", which is only for ODBC drivers. Only "UDL" and "non-UDL" methods are available for OLE DB, as we can see "DSN method and Non-DSN method" only in the case of "non-UDL mode" under OLE DB.
Let's take a look at the usage of ADO's object connection to establish a data source connection.
From the ADO reference you can see that the connection object has many attributes, we only talk about its two attributes, one is provider, the other is ConnectionString, the two related to our data source final connection.
The following section is about the provider attribute, copied to the ADO reference.
Use the Provider property to set or return the name of the connection provider. You can also set this property by ConnectionString the contents of the property or by the ConnectionString parameter of the Open method. However, specifying a provider in multiple places when you invoke the Open method can have unpredictable consequences.
If no provider is specified, this property defaults to Msdasql (Microsoft OLE DB Provider for ODBC).
You can also find this in the reference. Use the ConnectionString property to specify the data source by using a detailed connection string. And our ADO supports ConnectionString properties with only four parameters, two of which are for remote Data services, which means that for us,
It only supports two, which two?
Is provider= specifies the name of the provider to use for the connection. Oh, no, this just happened. Yes, and which provider attribute do the same thing, that is not only one! Yes, the only one is file Name. The file name= specifies the filename of the specific provider that contains the preset connection information, which is usually a file with a. udl suffix. As if this file name is not used by most people, miserable! So what do we usually use?
Don't worry, there's another word! "Any other parameters will be passed directly to the provider without ADO processing". That is to say we usually commonly used connection parameters in fact for ADO, is that it has been disposed of.
So, let's do this, and we're going to create a connection to the Microsoft Access database Mydb.mdb, for example
Using the microsoft.jet.oledb.4.0 provider
For me, I think of this connection as "the UDL way."
The first to create a udlfile.udl file is created using a process data connection property of the file Manager. You can do this by building an empty. txt file and then renaming it as. UDL to start the process generating the required OLE DB data connection. UDL document.
In this case, you can specify that the OLE DB provider is microsoft.jet.oledb.4.0,
The specified data source is C:\Inetpub\wwwroot\asp\adodb\MYDB. Mdb.
So we'll get a udlfile.udl file with the following content
[OLE DB]
Provider=Microsoft.Jet.OLEDB.4.0;Data Source=c:\inetpub\wwwroot\asp\adodb\mydb. MDB;
The UDL file is then used in the. asp file to establish a connection to the data source
<%
Set Conn=server.createobject ("ADODB. Connection ")
Conn. Open "File name=c:\udl\udlfile.udl"
%>
What is "non-UDL mode"?
means not creating a UDL file, but specifying it directly in the program, namely:
<%
Set conn=server.createobject ("ADODB. Connection ")
Conn. Open "Provider=Microsoft.Jet.OLEDB.4.0;
Data Source=c:\inetpub\wwwroot\asp\adodb\mydb. MDB; "
%>
As you can see, our usual use of this designation is a useful one. The connection string generated in the. udl file we know that Access databases can also use ODBC-provided drivers, in addition to this drive.
In this case, we still use the "UDL mode" and "Non-UDL mode" two ways to operate. In addition, because of the ODBC-driven, there will be DSN and non-DSN selection, we choose the "System DSN method", assuming the name MyDSN good.
UDL mode
Create a file udlodbc.udl in the same way as above, select the data provider for the Microsoft OLE DB Provider for ODBC drivers, and if you have already built the system DSN beforehand, You can select the name of the System DSN directly in the data source MyDSN, this seems to have some problems. It is best to choose to use "Generate connection string", click "Compile", then pop-up data Source Selection window, we choose Machine Data source tag, from which we can select the System DSN name MYDSN we have established, and then determine. In fact, you can recreate a new system DSN, and you'll see that the interface to create a new DSN is the ODBC interface. (As for how to create a System DSN I'm not going to elaborate)
So our udlodbc.udl is established, with Notepad open look, the content is roughly as follows:
[OLE DB]
PROVIDER=MSDASQL.1;
Extended properties= "DSN=MYDSN;
Dbq=c:\inetpub\wwwroot\asp\adodb\mydb.mdb; "
The following is the same as above, using the. udl file in an. asp program
<%
Set Conn=server.createobject ("ADODB. Connection ")
Conn. Open "File name=c:\udl\udlodbc.udl"
%>
So what is the "non-UDL way" in this case? Of course, the connection string is written in the program.
<%
Set conn=server.createobject ("ADODB. Connection ")
Conn. Open "PROVIDER=MSDASQL.1;
Extended properties= "" DSN=MYDSN;
Dbq=c:\inetpub\wwwroot\asp\adodb\mydb.mdb; "" "
%>
According to the default of ADO, we omit the part that can not be written, and become the following:
<%
Set conn=server.createobject ("ADODB. Connection ")
Conn. Open "DSN=MYDSN;"
%>
This is what we often call the System DSN method.
You can push the export File DSN method and non D
