Why isn't the Toronto VFP group going anymore? I hate to see that in a big city like Toronto.

Russell Campbell
President, Atlanta FoxPro Users Group, Inc.

>You should not use properties in rushmore optimizable statements at all. The performance is negatively affected by having to evaluate the property per row.
>
>>Well, that would probably be the first place I'd have gone, but I'm sure that with all the code I have running under VFP 7 I must have statements like this elsewhere, yet I don't remember running across this one before. How did the product get released if it can't handle a simple statement like that? It's frustrating.
>>
>>I did run across another strange one awhile back that was also solved by moving a field value to a memvar. I was scanning through one table and referencing a value in another table whose record pointer was not being moved. Yet I would get errors with this and moving the field value to a memvar solved the problem. There was nothing wrong with the code. It should have worked, but VFP didn't handle it properly. Hey, I love the language and VB has had and does have it's own problems as does every language, I'm sure, but silly stuff like this is irritating.
>>
>>Thanks for your input. Glad to know I've not gone looney (or not too terribly looney, at least).
>>
>>
>>>Hi,
>>>Yes, it happens to me too. The workaround is to store your property value to a variable before run LOCATE.
>>>
>>>HTH