It dwindled away while I was working in the US. I keep thinking to restart it, but don't really have the time.

>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