>Just something to think about...
>
>Selecting NO workarea is tricky by itself.
>Just a few examples. As you know, SELECT command selects only between existing workareas, or you SELECT 0 for unused area. Select NO workarea can be done only by closing the table in the current area. If you have the grid in the form, the specifically selected workarea automatically switches to the grid workarea if the grid gets focus.

Yes, that's why I've had a wish list item for some time to make this easier. And I suppose that grids will always present the problem. But SELECT 0 should always do the trick (except grids), no?

>
>Following a good naming convention for the fields and variables minimizes the possibility of mixing them.

But as you know, "good naming convention" is in the eye of the beholder! Some people, for instance, insist on using Hungarian (or a variation) even on field names!

I think that even over-using "m." is far safer than never using it.

cheers

>
>
>>You can significantly reduce the potential for surprises in the way VFP handles fields/memvars by running as much as possible with NO work area (alias) selected as current.
>>
>>A field name ALWAYS takes precedence - field names in the current 'active' work area that is.
>>This can bite in untold ways. A parameter name, for instance, can suddenly change from being a memvar to a field **if** a new field is added to the table that is active that matches the parameter name.
>>The same of course can happen for any memvar, not just a parameter name.
>>
>>By using the "m." explicitly when required (or even when not specifically required) you preclude sudden surprises caused by matching field names in tables.
>>I recall the m. as a throw-back to the old dBASE days and, personally I never use it. Does anyone have an argument for its use? Can anyone put their finger on the article to which I referred?