Mike Yearwood
Toronto, Ontario, Canada
General information
Category:
Forms & Form designer
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
Previous
Next
Reply
View the map of this thread
View the map of this thread starting from this message only
View all messages of this thread
View all messages of this thread starting from this message only