Was wondering if anyone might know how a SELECT statement would retrieve a non-existant key of the form: P OTECT (that's ASCII 129 as the second character). An error message is produced by READNEXT stating it can't read the key (obviously). Not sure if the error is a result of the SELECT (and an invalid key actually exists in the cursor), or if READNEXT is somehow messing up. Has anyone seen this happen before or have an idea on how to solve this problem?

Adrian Newman

Synergy & Associates

http://www.synergycc.com

I've seen TSRs do it, bad AREV assembler objects (like some of mine) do it, bad network cards do it, and bad disk drives do it. As there is no relationship between char(82)and char(129) in bit terms, it isn't the network card.

Is it repeatable, or just a one-off??

Steve

Try deleting the %RECORDS% record on the file - it may be corrupt. If it exists, it will hold all the the keys for the file so that the SELECT statement uses that insteaed of re-selecting all keys.

It possibly *is* an existing key and if so you can select records from that file starting with 'P' then do an 'EDIT filename' with the results using Alt/F to move through each record. The faulty record should display.

You need to then find out why it may have happened in the fist place. I hard several 'funny' characters generated in my data & programs some years back - it turned out that a faulty bit in a memory chip was corrupting every character that passed through it - what a mess!

Seems random. Out of approximately 50 program runs, it's happened twice. Know I've come across this before, but it was some time ago, and can't remember how the problem was solved. Can't recall if we had to replace hardware to clear it up.

The file causing the problem is quickdexed, but the record key P otect does not exist in %records%. Will test the system hardware and see if anything turns up. Thank-you for your help…

Take care.

View this thread on the forum...