The CONNECT_FILE BIF, Relative record number and last record read in Client/Server

Date: 4 October 2001
Product/Release: LANSA for Windows
Abstract: The CONNECT_FILE BIF, Relative record number and last record read
Submitted By: LANSA Technical Support

The CONNECT_FILE BIF is used to direct Client server I/O to one or more database files.

The third parameter of the BIF is the block size. By default, the value is 50. This means that 50 records will be returned to the client end of the application for each trip to the server. The data will still be processed in the sequence in which it exists in the particular file, and debug will still show the code looping through 50 records, but only one trip has been made to the server to retrieve the data.

Because of this, there are inherent dangers in processing that uses either the relative record number or the last record read.

Consider the following code.



On an iSeries server this is fine. However, in a client server environment, the value of RRN after the select will be the relative record number of the 50th record. The OAM on the server has performed one read action, and therefore has returned the LAST RRN it is aware of.

The same applies to the following code:



As far as the OAM is concerned, the last record read is the 50th record. Any attempted UPDATE or DELETE will be performed on the last record read.

Updating with a key to the file used in the SELECT loop is not allowed. Therefore, the only possible solution is to set the block size to 1. This will ensure that the data is returned one record at a time.

The down side of this is that the performance of the application is significantly decreased. It should be noted at this point that the most efficient way to update multiple records on the server is to run the update code on the server by using the CALL_SERVER_FUNCTION BIF.

A similar issue can be found in maintenance applications that allow multiple detail records to be opened.

A VL application displays a list of employees. The user can double click on an item in the list, and a maintenance form is opened. This receives the employee number from the list, and uses FETCH to read the data. FETCH has caused the OAM to read only one record. Before saving the changes, the user opens another employee detailer as well. The last record read value is stored in the OAM on the server, and as far as it is concerned, it was the second employee.

So, even though it was a FETCH that was performed, the employee maintenance form MUST update with a key. Any attempt to update the last record read will OVERWRITE the last record read.