(Written in April 2003) I am a beginner ASP. After a little deeper, let me confuse the database connection, I often see two ways to use for the same Microsoft Access database, or three, or even four The connection of the way, the most, I can't understand these two:
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
"Provider = microsoft.jet.Oledb.4.0; data source = databasename;"
%>
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
"DBQ = DatabaseName; Driver = Microsoft Access Driver (* .mdb);"
%>
Why is this this? With this problem, I started to systematically see the data source connection. Let me have something to show an ADO structure diagram for XMXOOo, and it is that I use the OLE DB data connection file (.UDL) file to create a data source connection. ADO structure diagram:
Let me talk about my general view of the data source connection.
The first thing to be sure is this ADO structure. The ADO mode is that all data sources must be accessed through the OLE DB interface, that is, ADO expects all data sources to provide drivers for OLE DB interfaces.
It is well known that all database management systems currently we use - DBMS can actually be visited through ODBC, because ODBC provides drivers for various data sources. However, the unified interface of the ADO accesses the data source is an OLE DB interface, so that although more and more database vendors have also provided OLE DB interface, such as SQL Server, Oracle, and Microsoft Access (Microsoft Jet Database Engine), etc., But there are still some data sources that cannot be provided in this way, but still need to be provided to OLE DB with the ODBC driver. In this case, the OLE DB defines an interface embedded using an ODBC driver, just like an ODBC driver is also an OLE DB model, like other database drivers. The name of the interface to the ODBC (ie the OLE DB provider) is Microsoft OLE DB Provider for ODBC Drivers, which is the default provider of the ADO. The value of the keyword Provider is MSDasql, which can be omitted, so we didn't see the provider when establishing a data source connection, that description, is definitely the driver provided by ODBC.
how about it? Confused my two nouns OLE DB and ODBC I finally see it.
In fact, it is simply that these two stuff can't wait, because it is not a category. ODBC is the Lord of Le Shan, which provides a driver provider for various data sources, and OLE DB is a dictator. It is yielded all of the data sources to provide the driver that meets its standard.
Next we use practices to prove this, our ODBC is indeed controlled by OLE DB.
Writing on the book is usually established a database usually has a "DSN method and non-DSN method", which can only be driven for ODBC. For OLE DB, only "UDL mode" and "non-UDL mode", because we can see "DSN method and non-DSN method", but it is "non-UDL mode" under OLE DB. Let's first take a look at the usage of the Objects Connection connected to the ADO.
From the ADO reference, you can see that there is a lot of attributes, and we only talk about its two properties, one is the provider, and the other is Connectionstring, which is related to the final connection of our data source.
The following is about the Provider property, copying the ADO reference.
Use the Provider property to set or return to the name of the connection provider. This property can also be set by the contentstring parameter of the Connectionstring property or the open method of the Open method. However, when calling the Open method, you may generate an unpredictable consequence when the Open method is called.
If no provider is specified, this property will default to MSDasql (Microsoft Ole DB Provider for ODBC).
You can also find such a bit in the reference. Use the Connectionstring property to specify the data source by detail the string. And our ADO supports only four parameters, two of which are still for remote data services, that is to say to us,
It supports only two, which two?
Is provider = Specifies the name of the provider used to connect. Worse, is this just there? That's true, and which provider property is the same, it is not only one! That's right, the only one is File Name. File name = specifies the file name of the file name containing a particular provider of the connection information, is usually a file that suffixes .udl. It seems that this File Name is not used by most people, it is miserable! What do we usually use?
Don't worry, there is another sentence! "Any other parameters will be passed directly to the provider without the ADO process." That is to say, our usual connection parameters actually treat ADO, which is handled by it.
Next, do it, we use the connection to the Microsoft Access database mydb.mdb to be used as an example.
Use Microsoft.jet.OleDb.4.0 provider
For me, I regard this connection below is
"UDL mode"
First create a UDLFILE.UDL file, which is created using a process "Data Connection Properties" using the File Manager. Can do this, build an empty .txt file, then rename it to .udl to start the process to generate the desired OLEDB data connection .udl document.
Here, you can specify the OLE DB provider for Microsoft.jet.OleDb.4.0,
Then specify the data source is c: /inetpub/wwwroot/asp/adodb/mydb.mdb.
This way we will get UDLFILE.UDL files with the following
[OLEDB]
Provider = microsoft.jet.OleDb.4.0; data source = c: /inetpub/wwwroot/asp/adodb/mydb.mdb;
After the .asp file, use the UDL file to establish the connection of the data source.
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
File Name = C: /udl/udlfile.udl "
%>
what is
"Non UDL mode"?
That is, it means that the UDL file is not established, but is specified directly in the program, namely:
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open "provider = microsoft.jet.Oledb.4.0;
Data Source = C: /inetpub/wwwroot/asp/adodb/mydb.mdb; "
%>
Everyone sees, we usually use this specified usage to use the connection string generated in the .udl file
We know that the Access database can also be driven by ODBC in addition to this driver.
In this way, we still use "UDL mode" and "non-UDL mode" to operate. In addition, since the ODBC driver is involved, there is a selection of DSN and non-DSN. We select "System DSN Mode", assume that the name is MYDSN.
UDL mode
Establish a file udlodbc.udl with the same way, select the data provider to Microsoft Ole DB Provider for ODBC Drivers, if you have built the system DSN in advance, you can select the system DSN's name MYDSN in the data source. This seems to have some problems. It is best to choose to use "Generate Connection String" and click "Compilation", pop up the data source selection window, we use the machine data source tab, from inside, you can choose the system DSN name MyDSN we have established, then determine. In fact, you can also recreate a new system DSN. At this time, you will see that create a new DSN interface is the interface of the ODBC. (As for how to create a system DSN, I will not say it)
So our udlodbc.udl is built, use notepad to open, the content is approximately as follows:
[OLEDB]
Provider = msdasql.1;
Extended Properties = "DSN = MyDSN;
DBQ = C: /inetpub/wwrow/asp/adodb/mydb.mdb; "
The next and the above is the same, use the .udl file in the .asp program.
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
File Name = C: /udl/udlodbc.ud "
%>
What is this?
"Non UDL mode"? Of course, it is also written in the program string in the program.
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open "provider = msdasql.1;
Extended Properties =
"" DSN = MyDSN;
DBQ = C: /inetpub/wwroot/asp/adodb/mydb.mdb;
"" "
%>
We will omit the parties that can be unwritten according to the default situation of ADO, which will become the following:
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
"DSN = MyDSN;"
%>
This is the system DSN method we often say. Everyone can derive the DSN method, and the non-DSN method is so
Document DSN method, assume that the file is named odbc.dsn
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
"Filedsn = c: /dsn/odbc.dsn;"
%>
Non-DSN method
<%
SET CONN =
Server.
CREATEOBJECT
"Adodb.connection")
CN.
Open
"DBQ = C: /inetpub/wwroot/asp/adodb/mydb.mdb; driver = {Microsoft Access Driver (* .mdb)};"
%>
Ok, these views are purely personal! Due to the limited level of this, I hope everyone will teach!
