Something for the weekend: Moving the record pointer

[Mike Lewis]

Well, it's been quiet here in the forum this week. I hope this lack of activity isn't causing your brains to go to sleep. Just in case it is, here is a little question to give you something to think about over the weekend.

You have a table open in the current work area. The record pointer can be pointing at any record (including EOF). There might or might not be an index order set. There might or might not be a filter in force. DELETED might be ON or OFF.

Your job is to write some code that will move the record pointer to the physical top of the file. By "physical top of the file", I mean the first physical record, not necessarily the first record in index order. This applies even if the record is marked for deletion, and if it is not included in any current filter.

You may assume that the table is not empty.

Apart from the change in the record pointer, the code should leave the environment exactly as it finds it (so if you change any setting, you must change it back again afterwards).

Easy enough, no? Kudos will go to the person who solves the problem in the least amount of code, that is, the fewest number of lines and the shortest lines.

(If you are one of the first to post a solution, consider using the [ignore][/ignore] tags to temporarily hide your answer so that others can have a shot.)

Mike

__________________________________
Mike Lewis (Edinburgh, Scotland)

Visual FoxPro articles, tips and downloads

 

[Olaf Doschke]

Oh yes, with #DEFINEs you can redefine many things.

We once had a timeout issue with a Linux Samba share and the FILE() function, rooted in how samba looked for file existences on non existing drives. It turned out, if you first split the full file name into drive, directories and the file name itself and used DIRECTORY() to first check the existence of directories before chcking file existence, samba was faster, so I wrote a myFILE() function and used #DEFINE myFILE FILE to redefine all normal calls to the native VFP FILE() function to call my user defined function.

Unfortunately the header file with this definition had to go in several places as I didn't set the Default Include File in Options->File Locations and you can't retrofit that. It's also set by the _INCLUDE system variable, but only applies to classes, forms and formsets you create after having set that and doesn't add an #INCLUDE in prgs.

Bye, Olaf.

 

[mjcmkrsr]

Hi,

From the "Bible" (Hacker's Guide ...).

Go, GoTo, Skip

These are two of the original commands in the Xbase language, useful for jumping to specific records while working interactively, but other commands have replaced their utility within programs in most cases.

Usage
[ GO | GOTO ] [ RECORD ] nRecordNumber | TOP | BOTTOM
[ IN nWorkArea | cAlias ]

Yes, you read the syntax diagram above correctly. This is the only command in the language where the command itself is optional. Type a record number all by itself into the command window, and the record pointer moves there. This trick works only with record numbers, and does not support the new IN syntax. Issuing just the record number works in programs, as well, but add the optional GO to keep from confusing people. Lines like:

&cRecNo
won't make sense to many people. The keywords TOP and BOTTOM go to the first and last records, respectively, in the current index order, or in the natural record order if the table doesn't have a current active index, obeying any filter in place. The IN clause allows you to move the record pointer in another area by specifying either the work area number or the alias of the table open in that area.

GO is not Rushmore-optimizable. Rather than using GO TOP or BOTTOM, use LOCATE instead—see the trick to it in "Faster Than a Speeding Bullet."

Many of us have used the trick of storing the record number to a memory variable, doing some processing, and then restoring the record pointer to its original position with GO. This still works fine in Visual FoxPro, but a common extension of the trick may not. If the record pointer was at the "phantom record," beyond the last true record in the file, issuing GO (nRecNo) would result in a "Record is out of range" error, so the trick was to store –1 as the record number if the record pointer was at the end of the file, and place the record pointer back there if so. This is a clever trick, but beware: If you are working on tables with table buffering enabled, Visual FoxPro actually does use negative record numbers for uncommitted buffered records. Consider using 0 (zero) instead.

Enjoy
MK