The visual FoxPro in my Eyes 8.0 (ii)

(iii) A new "connection"

Visual FoxPro 8 Enhancements in heterogeneous database programming, and more directly, improvements to SQL Server support. I think, at least in two aspects: one is through the CursorAdapter object to provide a more flexible than remote view, more easily programmable Cursor management object, another is based on the original concept of "connection", making "connection" processing more independent, "Connect" management more convenient , "Connection" is more easily shared!

We have already analyzed the cursoradapter in front of us, then let us see the change of "connection"!

1, "Connection" object and "connection handle" in DBC

When I introduced the connection in Visual FoxPro, I used to emphasize two concepts: the Connection object (component) and the connection handle in DBC.

The Connection object (component) in DBC is just a definition that describes how to connect to a data source through ODBC, and the connection handle is an instantiated connection object (component). We can get the connection handle by using the remote view or by opening the connection object with SQLCONNECT ().

Another two ways to get a "connection handle" in a more straightforward way is to use the connection string directly in Sqlstringconnect (), and the DSN definition in the SQLConnect () directly referencing the operating system (Odbc.ini). It should be noted that both of these methods skip the DBC "Connection" objects (components), making it difficult for visual FoxPro to manage them.

Before Visual FoxPro 8, the "connection handle" was not independent, the main thing is that remote view manages the connection handle itself, and other remote views or SPT need to share the connection handle, which is cumbersome, "connection handles" are shared between remote views, and all remote views that participate in sharing need to be defined The Shareconnection property for. T.;SPT to obtain a "connection handle" for remote view must use Remote view to obtain the connection handle using the Cursorgetprop () function. In addition to the trouble, there are functions that cannot be implemented, such as the "connection handle" that already exists in advance cannot be shared by remote view. All this is because the remote view is too autonomous!

2, Statement Handle Vs. "Connection Handle"

To resolve the "tyranny" of Remote View, visual FoxPro 8 presents the idea of "remote View" design-time separation from runtime, introducing a new concept of "connection" ――statement Handle, while Visual FoxPro 8 retains the "connection handle Concept

Any Handle that developers directly handle from Visual FoxPro 8 is Statement Handle instead of "Connection handle"! Further, "Remote View" is used by Statement Handle, SPT is also Statement Handle. That is to say, the connection that we are building and designing remote view in DBC can have nothing to do with the connection to the remote view runtime, and we can immediately specify the statement Handle that remote view will be used in the USE statement. This is an improvement in Visual FoxPro 8 "connectivity" for C/s programming.
The relationship between the Statement Handle and the connection handle. I thought:

The

• Connection handle is the basis for the Statement Handle, Statement Handle is the derivation of the connection handle;

• The connection handle is really connected to the data source, not the Statement Handle the developer directly operates on the Statement Handle rather than the "connection handle";

• A connection handle can derive one or more Statement Handle, and a single Statement Handle can only correspond to a certain "connection handle";

• Creates a new instance of a connection, and (possibly) produces a fresh "connection handle" and a new statement Handle that statement Handle corresponds to this " Connection handle;

• Creates a new instance of a connection, and if there is already a "connection handle" that meets the following two requirements in the current visual FoxPro system, the two requirements are: Allow to be shared, and the definition of the "connection" statement is consistent (which can be considered from The same "connection" object as the DBC. A new connection handle is not generated (no new ODBC channel is established with the data source). Instead, a new statement Handle is derived directly from the existing "connection handle", which statement Handle share the original "connection handle".

• The connection handle is released when the Statement Handle that is derived from a "connection handle" is all freed.

• Can derive multiple statement Handle based on a shareable "connection handle". The connection handle for

• must be created from the Connection object (component) in DBC. The connection handle created by using the connection string (Sqlstringconnect ()) or directly referencing the operating system DSN can only derive the only statement Handle. This is because Visual FoxPro determines whether different Statement handle are "homologous" based on the DBC "Connection" object (component) rather than ADO. NET, as defined by the connection string definition.

From the above statement, we found that: because the "connection handle" and Statement Handle relationship is "One-to-many", if you take SQL Server as a data source, we can create a "connection handle", based on its derivation of a number of Statement Handle, actually connected to the There is only one connection to SQL Server, and there can be multiple statement Handle in the application, which is a new concept of "Connection Sharing"!

3, an example

Let's take a look at the statement handle and the "connection handle" in the following example. There is a "Connection object" (component) named "CD1" in the DBC that connects to the SQL Server database.

Con1=sqlconnect ("CD1",. T.)
Connection succeeded, return con1=1. Con1 indicates that Statement Handle can later open remote view or perform an SPT command through this Con1, and since there is no "connection handle" in the system, a "connection handle" is generated and a "connection handle" needs to be obtained by:
Odbc1=sqlgetprop (Con1, "Odbchdbc")
I odbc1=49551184 here. This ODBC1 does not require a developer's attention or program maintenance.
Then we derive the other statement Handle according to ODBC1:
Con2=sqlconnect ("CD1",. T.)
Return to con2=2. Con2 represents Statement Handle, which can then be used to open the remote view or perform the SPT command on this Con2; we get the Con2 "connection handle" to look at:
Odbc2=sqlgetprop (Con2, "Odbchdbc")
I odbc2=49551184 here. Description, ODBC1 and ODBC2 is a thing that derives two statement Handle. Although, in programming, we can use Con1 or Con2, but the real connection to SQL Server is a "connection handle".
Next, we need to close all the statement Handle derived from the connection handle to really disconnect the visual FoxPro from the SQL Server.
SQLDisconnect (Con1)
SQLDisconnect (Con2)

This simple example may help us to understand the new "connection". Although Visual FoxPro 8 performed a major operation on the connection, this did not have much impact on the old system because the programming interface did not change, and visual FoxPro just added a layer of concept to the lower level. To say back, if you want to really use this new feature, or should change the programming mentality.

4, the "Connection" system changes the reason

Perhaps, we will have the question: Why does Visual FoxPro 8 join the concept of Statement Handle, by using the "connection handle" directly in the previous practice, is not also able to achieve "connection Sharing"?

The author thinks that this is the need of object-oriented programming and multi-layer development. The idea of the whole frame system is better object-oriented programming and better multi-layer development, so it has structured error handling, CursorAdapter and Statement Handle.

Above, I used the term "derivation", from the meaning of the word must be the "connection handle" to explicitly generate a new statement Handle, but from the instance code you can see that the Con1 and Con2 code is the same. In theory, Visual FoxPro is able to manage "connection handles" on its own, and developers only need to deal with the corresponding Statement Handle instead of having to care about other Statement Handle derived from the same "connection handle". This is good for modular development and solves the "shared connection" problem.

About the "Connection" topic talk about, but there is a problem is to note: A "connection handle" can be derived from multiple Statement Handle, in development, if there is a Statement Handle into the transaction processing state, All the relevant statement Handle are also in the transaction state, because SQL Server transactions are differentiated based on real connections--because of the requirements of a statement Handle, the "connection handle" is entered into the transaction state, which is, of course, " Connection handle "All statement handle derived are also entered into the same transaction. (Of course, statement Handle, which is not derived from the connection handle that has entered the transaction state, will not enter the transaction state.) ）

Having finally finished my "maiden Voyage" in Visual FoxPro 8, and figuring out some of the new features of visual FoxPro 8, I deeply appreciate a guiding ideology that runs through the framework of the entire Visual FoxPro 8, the idea of supporting a more perfect package of objects. This concludes that: using Visual FoxPro 8 for object-oriented programming, multi-layer development must be easier and more flexible than before!