Problem with GOTO TOP

[dgfletcher]

HI,
Hope this hasn't been addressed a hundred times. I didn't see anything in the FAQ.
I've run into wierd behavior with GO TOP or GOTO TOP. The command produces record out of range errors, but executes correctly from the command line. Using LOCATE with no specification does what is wanted, but why does GO TOP suddenly not want to work? The command is in as method, and the problem just may be more frequent since we started using private data sessions here and there. It sometimes messes up even with no indexes, filters or what have you active.
Any ideas?
Don

 

[EzLogic]

You might have some unwanted eof() in the file. Is your table in good condition? no corruption?

It happens alot with me when the table is corrupted somehow. and I run dSalvage.. and voila..

Ali Koumaiha
TeknoSoft Inc
Farmington Hills, Michigan

 

[dgfletcher]

Thanks, I'll check. I omitted to mention the problem is in VFP7.
It is weird that LOCATE works...

 

[mkrausnick]

I know you said it messes up even with no indexes set, but I'd still re-index the file and see if that helps. You might re-create the table with a simple "copy to" and re-index to see if that fixes it.

Mike Krausnick
Dublin, California

 

[Mike Lewis]

Don,

I agree with the what the others have said. "Record out of range" is usually either a corrupted table or a corrupted index.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[dgfletcher]

Thanks for all the input.
I'm going to go back and check the tables thoroughly. And see if I can recreate the problem reliably.
But, if recollection serves, in at least one instance, the GO TOP misbehaved on an unindexed cursor created a few lines earlier in the method (or do cursors have some sort of implicit indexing I don't know of?). By the way GOTO 1 caused us trouble sometimes too.
My hypothesis has been that VFP was losing track of the reccount somehow. Thanks again. Don.

 

[Mike Lewis]

Don,

Good luck with this. Let us know if you turn up anything interesting.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk

 

[dgfletcher]

Interestingly, if embarrassingly, the problem turned out to be buried in an include file which someone, helpfully trying to increase the "readability" of some code somewhere in the project, which had a preprocessor directive that redefined TOP as 0, that's zero. So GOTO TOP was being compiled as GOTO 0, which doesn't work.
My curmudgeonly refusal to fool with #DEFINE statements has saved me from this particular disaster in the past. Just in case the moral is not clear, DON'T REDEFINE KEYWORDS.

 

[Mike Lewis]

Don,

the moral is not clear, DON'T REDEFINE KEYWORDS.

I couldn't agree more -- as your unfortunate experience has demonstrated.

I don't often use #DEFINEs, but when I do, I usually put the definition in the same routine as the code that references it. Where a global #DEFINE is needed, I try to invent a word which couldn't be mistaken for a language element or field name.

Redefining TOP as 0 is unforgivable.

Mike


Mike Lewis
Edinburgh, Scotland

http://www.ml-consult.demon.co.uk