RecSize(), LUpdate(), RecCount()

These three functions return status information on a specified table based on information stored in the table's header. If your tables start giving you wacky results, and you're an intrepid enough hacker to hex-edit the header to fix them (make a backup first!), here are some clues as to how they are stored. All three functions return an empty value—0 for the numeric functions, and an empty date for LUPDATE()—if no table is available, but complain if passed a bogus alias. When passed a null value, all three functions return error 17, "Invalid table number."

Usage

nRetVal = RECSIZE( [ cAlias | nWorkArea ] )

Parameter	Value	Meaning
cAlias	Character	The alias of the table whose record size is returned.
cAlias	Omitted	If nWorkArea is also omitted, use current work area.
nWorkArea	Numeric	The work area containing the table whose record size is returned.
nWorkArea	Omitted	If cAlias is also omitted, use current work area.

RECSIZE() reports the size of a single record. This information is stored in bytes 10 and 11 of the file header, in low-byte, high-byte binary format. Unlike FCOUNT() and AFIELDS(), RECSIZE() returns the true length of each record, including the first byte used as the deleted flag, and the bytes of the hidden _NullFlags field (see "DBF, FPT, CDX, DBC—Hike!") if there are any nullable fields.

Example

CREATE TABLE sample (dDate D, ;
                     cTime C(6), ;
                     yCurrency Y, ;
                     nNumeric N(9,3), ;
                     mMemo M)
? RECSIZE()  && 36
COPY TO sample2 TYPE FOX2X
USE sample2
? RECSIZE()  && It took 54 characters to store in Fox 2.x!

Usage

dRetVal = LUPDATE( [ cAlias | nWorkArea ] )

Here's a function we were pleased to see changed in VFP 6. In previous versions, LUPDATE() reports the date the file was last updated, using the same parameters and following the same rules as RECSIZE() above. For VFP 5 and earlier, this information is stored in bytes 1, 2 and 3 of the file header in binary format—one character each for year, month and day, in that order. We pointed out in the first Hacker's Guide that this was not Year 2000 compatible. Well, someone listened. VFP 6 ignores the bytes in the file header and reads the directory entry for the date last modified.

For Visual FoxPro 5 and earlier, only the last two digits of the year are stored within the DBF header—updating a file in 1900 or in 2000 both store CHR(00) to byte 1. While the former is unlikely, you should consider several coding alternatives. If you're planning on having your code span centuries, you may need to test LUPDATE()'s return and add 100 to it if the current date is greater than 12/31/1999. Or write a roll-your-own type of ROLLOVER process. Or you could avoid this function altogether: Consider the FDATE() function instead.

Example

? LUPDATE("Customer") && Displays date last updated

Usage

nRetVal = RECCOUNT( [ cAlias | nWorkArea ] )

RECCOUNT() returns the current number of records in the table, using the same parameters and following the same rules as RECSIZE() above. This information is stored in bytes 4, 5, 6 and 7 of the file header, in low-byte, high-byte binary format. Obviously, this limits the maximum table size to 2,147,483,648 records, but this isn't a limit most of us will be too concerned with. While DOS is limited to only 2 gigabytes per logical volume, most of the more recent operating systems can easily handle the raw size of such a table. Throughput and raw I/O limitations, however, encourage more reasonably sized tables. The few demigods who manipulate data of this size have found several strategies to work around the limits: Segregate the data logically (A–M in one file, N–Z in a second), or partition by date or type.

Example

? RECCOUNT("Labels")  && 86 on our copies - yours may vary