>>If you call FSIZE() with a field that does not exist, it returns 0, rather than throwing an error. Although, I suppose, MS could argue this is "by design".
>>
>>So, watch out for typos with FSIZE().
>
>It's been posted here a couple of time that I've seen as a way to check whether a field exists instead of parsing the AFIELDS() output.
>
>Also, take note that FSIZE() returns different information depending on SET COMPATIBLE. If it's OFF (default) then it returns field information. If it's ON, then it returns the size of files (which is a very quick way to find the size of files and not parse the ADIR() output).
>
>< snipped >

Thanks, it figures that someone would have used this "feature" to check for field existence. I also like how Hacker's references SET COMPATIBLE STUPID when discussing FSIZE() and its related functions. :-)

What made me start this thread was an interesting bug. I was creating a custom cursor to power a grid, and one column was coming out with width 1 rather than 6 which was expected. I was using a SELECT - SQL basically as follows:

SELECT ;
    ..., ;
    SPACE(FSIZE("TypoFieldName", "ValidAlias")) AS cPlaceHolder, ;
    ...

The FSIZE call was returning 0, and setting anything to SPACE(0) is the equivalent of setting it to "" (empty string), but it looks like the SELECT - SQL *forces* the column to be at least length 1, therefore the result.

So, two interesting "features" in one SELECT - SQL !