Using VFP and SQL Server to build client/server application (remote View) (5)

Refresh buffer (refreshing buffers)

Remember that in the "Buffer Understanding Update Conflict" section we mentioned in what cases Visual FoxPro flushes the buffer. The "Remote View cursor is opened" is a good understanding, no longer described here.

Refresh the remote view cursor with the REQUERY () function

The REQUERY () function is to rerun the remote view's select-sql description, which is to reopen the remote view cursor, which is a significant burden on the system. For this function, I have a few suggestions:

1. Execution succeeded, returned: 1; On the contrary, the function returns: 0.

2. The execution succeeds, and the record pointer stops at the first record, because this function is like reopening the remote view.

3. This function refreshes the buffering completely because it is downloading the data again.

4. Under row buffering, if you modify a row of records but do not send updates, using this function, Visual FoxPro will send the update first, and if there is no update conflict, download the data cursor again; If an update conflict occurs, this function is not executed and returns 0.

5. Table buffer, if any records are modified, but no updates are sent, the function will not be executed, and a hint, as shown in Figure 11, returns 0.

Figure 11. The update is not confirmed under table buffering and the Requery () function cannot be used

Send update is successful, only buffer for related fields of updated record is refreshed

Perhaps this title is difficult to understand, then we will analyze:

1. Whether it is row buffering or table buffering mode, the send update is successful, and Visual FoxPro fills the new value of the updated field with a buffer. In other words, the buffer without the updated field is not refreshed.

2. The send update is successful under row buffering and only refreshes the buffer of the updated field for the current record.

3. The table buffer sends the update successfully, only refreshes the buffer of the updated fields for several records that are updated.

I think that Visual FoxPro so-called refreshing buffering is nothing more than a Visual FoxPro of its own behavior, regardless of the remote data source, that is, when the Update-sql statement is generated by Visual FoxPro, Visual FoxPro automatically fills the new value in the buffer, Visual FoxPro again sends this SQL description. So the refresh is the buffer of the updated field, and whether the update is successful or not!

Other properties of Remote view

The advanced properties of the remote view can be set by the visual tool, and we'll explain:

Fetchasneed and Fetchsize: Data required for remote access and number of records per fetch

These two properties work in pairs, and the default setting is:

Dbsetprop ("ViewName", "View", "fetchsize", 100)
Dbsetprop ("ViewName", "View", "Fetchasneed"). F.)

Indicates that when a remote view is open, 100 records are downloaded for each batch, and when the first 100 records are downloaded, Visual FoxPro will return control to the user or continue to execute the program. This is a problem: if several remote views share a connection, the connection may cause a blockage. As follows:

CREATE SQL VIEW vorders;
REMOTE CONNECTION Northwind SHARE;
As SELECT * from Orders
CREATE SQL VIEW vcustomers;
REMOTE CONNECTION Northwind SHARE;
As SELECT * from Customers
* Select the following command in the Command window and press ENTER
Use Vorders in 0
Use Vcustomers in 0
* pop-up "connect Northwind Busy" Prompt window

Let's analyze why: When a batch of Vorder 100 records is downloaded, Visual FoxPro executes the command to open the Vcustomers table, and there are two tasks for connecting to Northwind: Continue downloading Vorder's second batch of 100 records, Download the first batch of Vcustomers records, one connection cannot handle both tasks at the same time, so "connection busy."

To resolve the above issues, you can set this:

Dbsetprop ("Vorders", "View", "Fetchsize",-1)
* Indicates that all records are downloaded at once to complete this task before the control is returned or the program continues to execute.

If you set this:

Dbsetprop (' Vorders ', "View", "fetchsize", 100)
Dbsetprop ("Vorders", "View", "Fetchasneed"). T.)

Use Vorders
* Under 100 records, and return control to the user due to fetchasneed=. T., unlike just--visual FoxPro automatic control continues to download data, the connection is occupied
Go 100
* 100th record has been downloaded, so vorders no data, the connection was occupied
Go 105
* 105th record has not been downloaded to the client, so vorder download 5 data to meet the needs of users, the connection is occupied
Go Bottom
* Download all records, the connection is released

MaxRecords is: The maximum number of records to extract

This property refers to the number of records that the remote view cursor can download, and its precedence is higher than the two properties. That is to say, no matter how the two attributes are set, the client can only have a record that is less than or equal to the MaxRecords bar from the remote download, and after that number, the "Commandeer" Connection is released and available for other views. This property can be set like this:

Dbsetprop ("ViewName", "View", "MaxRecords", 25)

Fetchmemo is: Take the Memo field

If you have a Memo field in a remote view, it is generally considered that it is meaningless and inefficient to download the data to the client at once, and the network traffic is soaring. It is better to use the time to download. The so-called use of the time is refers to: obvious or implied Modi memo command. You can set its properties this way:

Dbsetprop ("ViewName", "View", "Fetchmemo"). F.)

Comparememo is: Include a Memo field in the WHERE clause

This property is important when a remote view contains a memo field or a common field. The default value for this property is. T., that is, when detecting update conflicts, the two fields are treated the same as other types of fields. The author thinks, this kind of setting has an unreasonable, a mistake, please listen to my way:

First of all, when a generic (excluding "Memo field") field is set to updatable, and the update Conflict detection method of "keyword and updatable fields" or "keywords and updated fields" is used, Visual FoxPro does not allow this setting. Visual FoxPro does not point out this error during the view design phase, but an error message occurs when the Update-sql is actually sent.

"Unreasonable" is being said. I've just pointed out that memo fields can participate in update conflict detection, but this is a great pressure on the server and a lot of pressure on the network.

So in general applications, we'll set the value to. F., that is, when the update conflict detection mode is "keywords and updatable fields" or "keywords and updated fields", the Visual FoxPro sends Update-sql to remove the two types of fields from the Where clause, even if the Memo field or generic field client program is changed. This will avoid the "one mistake, one unreasonable" I have put forward.

You can set this:

Dbsetprop (' vemployees ', ' View ', ' Comparememo ',. F.)

Field Properties

DefaultValue

If you want to perform a append command on a remote view, the system automatically fills in the relevant fields, and it is necessary to set this property:

Dbsetprop ("Myview.myfield", "Field", "DefaultValue", ". T. ")
Dbsetprop ("Myview.myfield", "Field", "DefaultValue", "' Bob '")
Dbsetprop ("Myview.myfield", "Field", "DefaultValue", Date ())

DataType

The following is a comparison of the Visual FoxPro field type with the SQL Server field type:

SQL type	Visual FoxPro Type
Binary, varbinary	Memo
Bit	Logical
char, varchar	Character
datetime, smalldatetime	Datetime
Decimal	Numeric
Float	Double
Image	General
int, smallint, tinyint	Integer
Money, smallmoney	Currency
Numeric	Numeric
sysname	Character
Text	Memo
Timestamp	Memo

You can set this:

Dbsetprop ("Vemployees.birthdate", "Field", "DataType", "D")

UpdateName

This property is important in multiple tables, and many columns in multiple tables may have the same name, so you must explicitly tell the remote view how the columns in the view correspond to the columns in the Data source table. Such as:

Dbsetprop ("Vcustomers.postalcode", "Field", "UpdateName", "Customers.postalcode")