>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