>Mike,
>
>>I'd like to agree with that but, it's never that simple. Field didn't always accept the field name. Hence the use of type etc.
>
>I do not understand you, are you advocating not using new functions just because there were not available in previous versions?

No. I mean a UDF opens the door for easily switching to a new function. If IsField used type(), it could be switched to use field() in a second.

>I know Field has been changed in VFP 7 or 8 to allow a char, and believe me if I saw the original poster showed in his version info he was using a previous version, things would be different, I wouldn't have suggested the use of Field. And also believe me when I will not call any function written by other as "useless", something it really bothered me from the guy to whom I replied.

I wish that wasn't such a concern but it is. If someone writes a goofy function it behooves us all to get that out of the way quickly. ;)

>>In fact the sample code for FIELD() even now does not show that it accepts anything but a number. ;) A UDF is supposed to encapsulte the complexities. An IsField UDF does the job while allowing our code to improve while never needing to go back and replace all TYPE() with FIELD().
>
>What do you mean with "even now does not show that it accepts anything but a number"? Both intellisense and help show that you can use a character or a number.
>

>Returns the name of a field, referenced by number, in a table.
>FIELD(nFieldNumber | cFieldName [, nWorkArea | cTableAlias [, nFlags]])
>

>

Please don't take a part of a sentence and reinterpret the entire sentence like that. What are you? A news reporter? ;)

I said the *SAMPLE CODE* (which excludes the syntax portion of the help and intellisense since it only shows the syntax) for field() - perhaps I should add "in the help" - even now does not show that it accepts anything but a number.

>
>>
>>Further, the penchant to write a formula off the cuff yields code that is unreable. Even the formula "TYPE('something')" cannot be deciphered as easily as "IsField('something')".
>
>Not sure if you meant unreadable or unreliable, but I disagree in both counts. While I agree isField (jeez, not even in the spelling case of the functions we agree <g>) is more readable, I would not say type in unreadable, but I agree it would require a more "experienced" reader.

Less readable then.

>Do not get me wrong, I like to have functions, lots of them, but, as a self confessed speed freak you are <g>, what would you use in a select statement or a tight loop, a slightly unreadable built-in function or an UDF that does the same but is slower?

Actually, I do have alternatives. My FoxPro Advisor SnippetFactory article demonstrates a way to inject a formula from a table into a SQL command and execute it, with performance similar to hand-coding, while providing the maintainability of the UDF. http://advisor.com/doc/17440

Thomas Ganss recently showed a very cool and fast technique for using a #DEFINE which can do something similar. It's not as flexible as my SnippetFactory. Had you used TYPE() you'd have a struggle to change to FIELD().

#define IsThereAFieldCalled !SPACE(0)==Field
*-- Space may be a tad slower than "" or '', 
*-- but removing the string marker makes it less brittle  
*-- in case of string-building for eval-situations
for x = 1 to m.lnStop
  y=IsThereAFieldCalled("rowguid","pubcur")
endfor x

>[Update]
>
>Mike, reading again the help and you know what? I agree that in this case it would be better to encapsulate it on a UDF, I did never noticed before that FIELD can raise an error.

x2. One if the alias is not there and another if the field is an expression that cannot be evaluated.