FYI -

On previous post, we are running AREV v2.12 currently.

I have seen this occur. Earlier this year there was a post that indicated how to get rid of the offending row/record in a simple straight forward manner.

My solution prior to that time was to create a new_data_file and then write a routine that would copy the valid records to the new_data_file based on certain criteria such as a data field/column that had to have data in it. If the field was blank, the record would not be copied. I would then rename the old_data_file to something else and rename the new_data_file to old_data_file and reset the indexing, etc.

I wish that whoever made that previous posting would do so again. Otherwise my solution works although a bit tedious.

My problem was caused by a routine that picked up a piece of information in a certain field/column and wrote it to that row with the same name. If the field was empty it wrote the new information to a record with the key being blank. Am I clear as mud here?

Dale

dale_walker@integrity.com

Dale,

Thanks for the suggestion. I viewed the data file (not large at all ~835 records), and there are no blank keys, as well as there are no blank fields in the fields that are indexed.

If I put the btree index on the field (the field name is size), and do a select, then AREV will not return correct information, i.e. -

I know there are 98 records with a certain "size". If I remove the index from the field called "size" and do a select statement, it will show all 98 records.

If I put the btree index back on the "size" field, and do a select statement, it will only select 45 records -

very very strange.

We have never had a problem with the selections before I upgraded the file server (hardware only).

With only having ~850 records, it does not take long for a selection without having indexes on the fields, but of course everyone wants the speed, so it would be nice to have the speed with accuracy.

There is a patch available for 2.12 in the download section. I forgot what it addresses but it probably wouldn't hurt to install it.

Leon,

I know there are 98 records with a certain "size". If I remove the index from the field called "size" and do a select statement, it will show all 98 records. If I put the btree index back on the "size" field, and do a select statement, it will only select 45 records - very very strange.

One issue that I am aware with on indexes is that they are very picky on how the dictionary is set up. If the data is numeric, make sure the dictionary is right justified. Also, make sure that the default length in the dictionary is large enough to accomodate the longest piece of data.

HTH,

msorrel@greyhound.com

View this thread on the forum...