My two cents:

I would agree with Stuart, although I don't know enough about the technical details.

Thanks to this thread, I learned that it is possible to do a select to a file-variable in UV-Basic. I did a short test with our file "ARTIKEL" on our test server, and it turns out that there is only a very little performance gain between the two selects.

The file with all items has about 1,600,000 records. I did a small test to read every single item without changing anything.

• If I select the whole file with ">:SELECT ARTIKEL" and step through the list with READNEXT, it takes between 9 and 10 seconds for the whole process, while the select taking about 4 seconds.
• If I select the file variable with SELECT FV.ARTI, the processing starts immediately without a noticeable delay for the select but still takes between 8 and 9 seconds to process the whole file.

Therefore, I also prefer the SELECT of the file before processing it instead of the file variable and enjoy the benefit of doing it the same way every time.
The performance gain in this case for me sounds too small...

Greetings
Thomas

One effective way to read a file record without a SELECT list is by using the XLATE function, which operates on a single key and retrieves specific data from a file based on that key. Here's an example:

EMP.REC = XLATE("EMPLOYEES", EMP.ID, -1, 'X')

IF EMP.REC = "" THEN
    ERR.MSG<-1> = "Employee record with ID " : EMP.ID : " is no longer available."
    RETURN
END

In this example, the line EMP.REC = XLATE("EMPLOYEES", EMP.ID, -1, 'X')  is used in UniData to retrieve the entire record associated with a specific employee ID from the EMPLOYEES file. The  -1  attribute tells  XLATE to return the entire record rather than just a specific field. The 'X'  mode ensures that if the key (EMP.ID) is not found, the function returns a null (empty) string, allowing you to handle the absence of the record gracefully. XLATE does not require opening the file explicitly.

If the record is missing, an error message is generated, indicating that the employee record is no longer available.

Best Regards,

Koteswara Rao Naidu(Koti)

One effective way to read a file record without a SELECT list is by using the XLATE function, which operates on a single key and retrieves specific data from a file based on that key. Here's an example:

EMP.REC = XLATE("EMPLOYEES", EMP.ID, -1, 'X')

IF EMP.REC = "" THEN
    ERR.MSG<-1> = "Employee record with ID " : EMP.ID : " is no longer available."
    RETURN
END

In this example, the line EMP.REC = XLATE("EMPLOYEES", EMP.ID, -1, 'X')  is used in UniData to retrieve the entire record associated with a specific employee ID from the EMPLOYEES  file. The  -1  attribute tells XLATE  to return the entire record rather than just a specific field. The 'X'  mode ensures that if the key (EMP.ID) is not found, the function returns a null (empty) string, allowing you to handle the absence of the record gracefully. XLATE does not require opening the file explicitly.

If the record is missing, an error message is generated, indicating that the employee record is no longer available.

EXECUTE "LIST.ITEM FILENAME NOPAGE HDR.SUP" CAPTURING SCREEN

Some parsing required.

I go for the easy answer

INPUT ID

READ REC FROM FILE,ID ELSE

   CRT 'RECORD NOT FOUND'

    STOP

END

CRT ' Got record : ':ID

END

Well isn't that interesting!

In that same vein, one could do:

EXECUTE "COPY FROM FILENAME CRT NO.PAGE ALL" CAPTURING SCREEN

You could also do something like this, assuming a static file:

OPENSEQ "FILENAME" TO FILE ELSE STOP

STATUS INFO FROM FILE ELSE STOP

SIZE = INFO<6>

READBLK DATA FROM FILE, SIZE ELSE STOP

Of course, that might be a bit more difficult to parse.

Hi All

Yes, it is possible.

It's been more than 20 years since multivalued system was my focus, so I am rusty, although I still occasionally dabble with uV Personal Edition.

At some stage during my 12 years working for Prime Australia as a Prime Information systems engineer, I learned the 'Drumheller Trick' which was conveyed by John Drumheller. John was the chief architect of Prime Information from Devcom, the original PI developers.

Essentially, his trick was to construct a subroutine that will do the processing for each record in a file, and this will be used in an I-type descriptor.

Here's a simplified use case where there is a transaction file TRANS and a customer file CUSTOMER. The TRANS records will be used to update the CUSTOMER records. The following sample subroutine will be used in a TRANS I-type.

      SUBROUTINE EOD(RESULT)

      COMMON /FILEVARIABLES/CUSTOMER

      IF NOT(ASSIGNED(CUSTOMER)) THEN

         OPEN '','CUSTOMER' TO CUSTOMER ELSE STOP 'CANNOT OPEN CUST'

      END

      REC = @RECORD

      AMT = REC<1>        ;* transaction amount

      CUST = REC<2>      ;* customer ID

      READU CUSTREC FROM CUSTOMER,CUST ELSE STOP 'ERROR'

      CUSTREC<1> += AMT        ;* update balance

      WRITE CUSTREC ON CUSTOMER,CUST

      RESULT = ''

      RETURN

   END

This subroutine is catalogued and used in an I-type named EOD.PROCESSING by way of example, where line 2 would be:

                SUBR("*EOD")

Then you simply do:

LIST TRANS EOD.PROCESSING

No SELECT is performed, just a LIST statement.

I remember applying this approach to the end of day processing for a regional building society who were using select lists and the end of day processing no longer completed within the required window. This vastly improved performance and the EOD process went back to an acceptable timeline.

BTW if anyone in Australia is looking for a dinosaur to cut code, I would love to hear from you.