The following code segment creates a LATENT FILE-BASED list:

…

OPEN 'ORDERS' TO DATAFILE ELSE FSMSG()

SELECT DATAFILE

…

How can I determine the total amount of records in the file?

(@reccount requires an active RESOLVED list and does not apply here.)

Is there a practical way to retrieve the record count shown by DUMP from within a program?

Thanks in advance

Wilhelm Schmitt

I usually do a :

OPEN 'ORDERS' TO DATAFILE ELSE FSMSG()

PERFORM 'SSELECT ORDERS'

IF @RECCOUNT THEN

FOR I=1 TO COUNT(@RECCOUNT,@FM)+1

NEXT I 

END ELSE RETURN

Wilhelm,

If you require a latent select list then you can use the Get.RecCount function to get the current record count that DUMP would show. The syntax is:

rowcount=Get.RecCount(filevar, status, forcecount)

Setting forcecount to 1 will cause the table to be counted again so you probably want to just pass a 0 for speed purposes.

[email protected]

SRP Computer Solutions

Hi Don,

Looping through a file, the get.reccount function (with forcecount=0) showed approx. 590,000 record. When the programm was done, the record count jumped up to 639,000 approx.

Looping through the file for a second time get.reccount (forcecount=0) stated 639,479, but the loopcounter within the programm finished at 595,040.

How should I interpret the 7.5% difference?

How can I find out the real number of records in the file? (forcecount=1 ???)

TIA

Wilhelm

Wilhelm,

Setting forcecount to 1 will provide an accurate count of records in the table. However, this simply does the same thing as a COUNTROWS command so you will experience a delay while the table is being physically read. If the difference between the real count and the header count is negligeble in terms of displaying status information then I wouldn't worry about it. I'm not an expert on explaining how and when the table count gets updated routinely so I'm not sure how far off you should expect the difference to be…especially with as many rows as your table has.

[email protected]

SRP Computer Solutions

Don,

My main concern is to know, if the loop counter gives me the real number of rows. Because if this was not the case, how then could I ensure, that -after SELECTing DATAFILE- the programm passes through each of the record keys.

What happens, when a user on the LAN adds a new record, after the SELECT is done. Is that included or excluded in the loop, or does inclusion depend on the position in the file? Given the actual size (]700MB) of the file there is not much resizing going on.

With a big file, it would slow down processes considerably, if I wanted to update (COUNTROW) each time.

Thanks for your help.

Wilhelm

The record count in the file header is updated with every I/O operation (add/delete). So….. If you issue a GET_RECCOUNT now and then do a latent select (SELECT filevar) and a read loop, you may see a difference as records may be added all the time. If you must guarantee that you are updating a known (and therefore static) file, you should do a non-latent select (TCL). The @RECCOUNT variable will contain the number of keys returned (which should match the readnext counter). Any process that is updating (and particularly adding) records to a file should definitely NOT use a latent select. It is easy to stumble over your own record and process it again. We have an accounting app that generates service-charge detail records based on the A/R open status of transactions. A latent select can easily hit the record written and process it again.

Don Miller

C3 Inc.

View this thread on the forum...