How does ADO lock RecordSet records?

SET RS = Server.createObject ("AdoDb.Recordset")

RS.Open SQL instruction, conn, 1, 1 'read RS.Open SQL instruction, CONN, 1, 3' new, modified, or delete

What does the third parameter 1 and the fourth parameters of RS.Open have mean? Why is the fourth parameter to use 1, new, modified, or deleted when reading?

The third parameter represents the CURSOR type; the fourth parameter represents the lock type of the Recordset.

The detailed introduction is as follows:

Recordset lock

When you open the Recordset object, you can also specify the lock type with the LockType property:

1: Readonly, not allowed to update, for the preset value. 2: Pessimistic Lock, in editing the Recordset data or using the AddNew method, immediately lock this record or contain the information page containing the data record, and maintain the lock until you use the UPDATE method to write the change back to the database. 3: Optimistic Lock, use the UPDATE method to lock back to the database when it locks this record. 4: Batch Optimistic Lock, use the UpdateBatch method to write a multi-change record batch back to the repository before locking this batch record.

When you use Pessimistic Lock, once you edit the RecordSet data or call the AddNew method, you will lock the information corresponding to the current editing Recordset until it is clearly confirmed or canceled with this Recordset's change. The lock will be released. The main advantage of pessimistic lock is to obtain the lock, as long as the Recordset is also locked, no lock conflict will occur. Since a user begins to edit the Recordset, other users cannot change it, so pessimistic lock is the only way to ensure that the application can read to the current latest information. The shortcomings of pessimistic locks are in editing and locking the Recordset, and the entire information corresponding to the Recordset will be locked. If the user has been clearly confirmed or canceled during the Recordset lock during the Recordset, it will generate a problem, not only locking the user who is editing the Recordset, And it is also possible to lock the other RECORDSET in the corresponding page of the locked data. When you use an optiac lock, you will only lock the data corresponding to the use of the UPDATE method, so that the locking time is the shortest, which is the main advantage of optimism. The drawback of optimistic lock is that when the user begins to edit the Recordset, it is unable to determine if the update will succeed. If another user changed the RECORDSET, the first user is editing, the update built in an optimistic lock will fail. For example, A and B are edited the same recordset, if the A. is optimistic to edit a Recordset, because the use of the use is optimistic lock, and does not really lock the Recordset, so it cannot be prohibited from trying to edit the same RECORDSET. So B starts to edit the same Recordset. However, B also does not know that the armor is editing the Recordset, and it will not see the latest information. Because B is also editing the information record, it will receive an error when the A Try to store his changes. Optimistic lock will be converted into pessimistic lock when you use the Transaction function. Because of the ability to write a Write-Lock before you make a transaction confirmation (CommIT), it is transformed into pessimistic lock. Optimistic Update is performed by a scriptual record. You can make the user can change the change of multiple records in its own computer, then use batch processing, and transfer these multi-change records to the server for updates, so efficient is relatively high. This method is called batch optimistic update. Batch Optimistic Update Using the Lock Mode for Batch Optimistic Lock, which locks this batch record when using the UpdateBatch method back to the repository using the UpdateBatch method. When the lock is set on the RecordSet object, if the lock fails, an error is generated. For example, another user turns on the Recordset object when the user is locked, then an error occurs when you try to lock the RecordSet object. The error may be: 3260: Recordset is locked.

When you encounter this error, you can wait, then try again. 3262: Unable to lock the information table , is currently being used by the user on the machine . Wait a minute, then try again. 3197: The information of Recordset has changed after being opened. Because you and another user try to change the same information at the same time, you can try again to reread the Recordset to achieve the latest information. 3186: Unable to store, currently being locked by user on the machine . This error occurs when a user attempts to update a data corresponding page, and this page is locked by another user. To handle this error, wait for a while and then reserve the Recordset. 3260: Cannot be updated, currently, the user is locked by the machine . When you edit the RecordSet data or call the addNew method, the information corresponding page contains this error to handle this error, wait for a while, then save the Recordset again. Or you can notify the user who encounters this problem and allows the user to choose whether to retry this operation. Cursor

CURSOR is a collection of indicators or indicators that point to information retrieved from a database in accordance with a certain condition. The characteristics of Cursor are as follows:

You can represent partial or all RECORDSET in a single data sheet. Particular or all RECORDSETs in the joins of the multi-data table can be represented. It can represent no recordset. At the Cursor level or at the information field level, the Cursor can be read-only or updatable. CURSOR can either bidirectional (indicating that it can move forward or backward in the Recordset), but also move forward only. Cursor can exist in the client's computer or there may be on the server.

Cursor location

Cursor requires a temporary resource to store information, which is RAM, virtual memory, temporary archive or database. If these resources are in the user's computer, Cursor is called a Client-Side (client) Cursor. For this type of CURSOR, the server transmits the information represented by Cursor to the user's side, and manipulates the temporary resource by the user. Another type of Cursor, called Server-Side (server side) Cursor. For this type of CURSOR, use the temporary resource on the server to manage the Recordset object. For Server-Side Cursor, only Recordset selected by Cursor is transmitted to the client through the network. Therefore, when there is a problem in network communication or frequency width, this type of Cursor is used to improve in performance. However, because resources such as RAM and disk space on the server are required, it is necessary to ensure that the server has sufficient resources to manage the Cursor of all client computers. CURSORLOCATION properties, you can choose the location of Cursor, is on the user-end computer or on the server:

3: Use the user end CURSOR. This option is better to the small Recordset effect, but its performance has fallen rapidly. 2: Use the server Cursor. This type of Cursor has better performance for most large homework.

CURSOR Type When the Recordset object is turned on, you can specify a different Cursor type at the Cursortype property: 0: Forward-Only (only forward): You can only move forward, this is the default. 1: KeySet 2: Dynamic 3: Static (Static)

If the application only needs to read a Recordset, do not need to do new, modify, delete actions, then use Forward-Only Recordset object, it can significantly improve the performance performance of the application. Note that the following methods and properties will not be used when using Forward-Only Recordset.

.Bookmark properties .clone method .MOVE method .Movefirst method .Movelast method .MovePrevious method. OpenRecordset method