>>My answer is that "it depends". If the SQL is something that only grabs a few records here and there, the performance hit for using a UDF won't be that noticable an I would go ahead and do it. On the other hand, if you are grabbing thousands of records, there could be a significant hit. In that case, filling the SQL with an empty field, and then using a SCAN loop to go through the cursor and apply the UDF to the field is the way to go. When in doubt .. do a timing test with doing it both ways and see what the difference is.
>
>Your response seems to imply that using the UDF inside the SELECT would be OK. Others have advised against this for reliability reasons. Or do I misunderstand? In practice it has always seemed to work OK. So I don't know what the issues are.

There are several things to consider.

First, the speed: depending on how much code is there in your UDF and what does it do, it will execute for every record, so even if it does nothing, you incur the cost of the call _tally times at least.

Next, the context. You can't really be sure what's the current alias while your UDF executes - I haven't really tried, but it would be interesting to see what aliases are available if your select involves multiple tables. Which leads to another matter - you can't assume anything about aliases within the SQL statement; any function using an alias as a parameter is basically unusable except in single table queries (which can be then used as a workaround - select from that one table into a cursor first, and add columns where to store the results of such functions, then join that with the rest). So... while scripting in Fox gives you enormous freedom, in this context you may exercise some constraints as your code isn't entirely free, it runs as an inline function. It would be interesting to try, if anyone cares to, launching a dialog or printing a report from such an UDF.

Also, your UDF may be interrupted. Not sure of that (I am not using them in SQL statements), but my hunch is that they are running as simple prg scripts which can possibly be interrupted by a, say, OKL or something. Which can lead to interesting results, maybe.