>Hi Ben,

>Yes, it is bad that STR() is not optimized when it should be. It is limited to inexact >comparison only, i.e. SET ANSI is OFF. Is that the type of comparison you were >targeting in your projects?

>Thanks,
>Aleksey.


Hi Aleksey,

SET ANSI OFF is necessary at least in some circumstances. For example, a set of detail lines of an invoice may be retrieved by the following statement:

SELECT * FROM InvDetail WHERE InvoiceNo+STR(InvLineNo)='INV00001'

Here, InvoiceNo+STR(InvLineNo) is the primary key of the InvDetail table. (see message#051026 for more info)

Of course, I can think of a number of workarounds to the problem. However making such change to a large project is unfortunate and time consuming. I'd rather wait for a VFP9 service pack.

If you agree that VFP should optimize STR(), I think you will also agree that VFP should optimize other string functions (LEFT(), REPLICATE(), LEFT(), RIGHT(),...) when the parameter determining the length of the resulting string is a numeric literal. Therefore, the bug in VFP9 is not limited to STR().


Ben