What causes this? I have a file that contains 2 records. TCL List, Edit and Select commands correctly identify 2 records. Dump shows the RowCount=3. And a custom function that reads the file header to extract the record count comes back with Zero. (function has worked fine for 6 years!) Any ideas??

Mark,

Not sure if this is the cause of your problem, but I have seen similar behavior when there was a RIGHTDEX on a file that somehow became corrupted.

Matt Sorrell

msorrell@movgal.com

The header in frame 0 of your version 1.1+ file has a record count. Previous versions do not have a record count. Issuing a COUNT filename LATENT on a version 1.1+ file will return the value in the header (the same as you see in DUMP). Omit the LATENT keyword, and the system will scan the entire file and update the record count in the header. This is how you can correct a header that is incorrect.

However, if you have a quickdex or rightdex on the file, an additional record, %RECORDS% is saved on the file. This record IS included in the record count stored in the header but is NOT included in the result returned by COUNT. Why the discrepancy? Well, the MFS (QUICKDEX.MFS or RIGHTDEX.MFS) that maintains this record is really the only part of the system that is designed to have any knowledge of %RECORDS%. With the MFS installed correctly, it will not appear on lists, selects, etc., so including it in record counts would not be appropriate. On the other hand, the MFS needs to see the file at a lower level and may need an accurate record count including this record.

I hope that was clear. If not, just be aware that if you have a quickdex or rightdex, there is an extra record, %RECORDS% that serves as the index for the quickdex or rightdex. The existence of this record is what is skewing the numbers.

The DUMP command will show the file version in the upper left corner. Stephen Thomas had a utility to convert the headers from 1.0 to 1.1. It may be available in the ALL.ZIP in the download section. If not, recreate the file.

Okay, I'll buy that for this example. How about a file where an RBasic Select comes up with 315,000 records and a TCL Select comes up with 800,000 records?

P.S. I left this out of the original message, but in case it matters, I'm running AREV 3.12 on a stand-alone PC.

There is one other thing that can affect the count. If you do a select sorted BY a multivalued field, then the record count will be the total number of values. So, for example, if you have two record, with three values each in the field that you sort-select by, you would get 6 "records" selected. With this kind of select, you need to use the READNEXT ID,WHICH_VAL … syntax to get the current value. If you have a saved list you can edit it and see value marks for each row. The value before the @VM is the key and the number after to @VM is the value number that will be returned in WHICH_VAL.

Perhaps this is what you are running into. If not, then I suspect a corrupted header, which can be corrected by issuing a COUNT filename from TCL.

That's a good point Victor. Unfortunately it's not the case. I avoid multi-values as much as possible. And when I issue a COUNT command at TCL, it does not fix my problem. Any more ideas?

Delimiters in keys maybe? This is just grasping at straws (since I have not really encountered this situation), but I can see how it could perhaps cause your symptoms.

Mark,

One other possibility that we just encountered is bad RAM. We were pulling our hair out trying to figure out why different methods of counting rows kept reporting different numbers. Then we were really worried when the same method kept giving us different numbers. Then we started getting phantom GFE's and that clued us in on the true nature of the problem.

dbakke@srpcs.com

SRP Computer Solutions

Just had an example in a file where COUNT would return 1055 and SELECT would return 1048. When I selected sorting by one field (SURNAME) SELECT would return 1047. When I selected sorting by two fields (SURNAME AND FIRST_NAME) SELECT would return 1046.

I have no idea why COUNT is returning 1055. I have no quickdex or rightdex on the file, however, there are two btree indexes. When I rebuilt all the indexes in the file, both the SELECT commands with the sorting started returning 1048.

In other words, SELECT can be confused by a corrupted index file.

Douglas Hahn

Platinum Pro Ltd.

If you do a select BY a field with value marks in it, there will be one hit per value.

View this thread on the forum...