Srdjan,

The question, of course, then becomes, "What should it do instead?" If you do a scatter with fields that have the same names as your variables, and VFP therefor sets memory variables named differently from the fields so as not to conflict with the memory variables you're already using, how will you know what you have any more? How would you find those new memory variables put out by the scatter?

I can understand not liking it, but I have a real hard time picturing what should happen instead.

I think that the way it's handled is logical and workable (once it's understood), and that anything else just might create a nightmare of confusion.

Alan

>P>Srdjan,
>>
>>But this is already well known by VFP and it has the "m." to take care of it.
>
>As I said, I understood what is happening and I took care of it
>point is that one error message would make all the difference ...
>
>Perhaps u hv code builded up in the functions and classes (framework developed years ago) and all of sudden u run across table that HAVE to have field(s) named this way. Even if u used m.xx all along u would still run into problems when u deal with scatter/gather constructions to populate data - again u will run into problems as I will show in this example:
>
>

>local   m.lLocal
>private m.lPrivate
>public  m.lPublic
>
>store .t. to m.lLocal , m.lPrivate  , m.lPublic
>
>=form_call()
>
>if m.lLocal = .t.
>    wait wind 'Local ok'
>else
>    wait wind 'Local not ok'
>endif
>
>if m.lPublic = .t.
>    wait wind 'Public ok'
>else
>    wait wind 'Public not ok'
>endif
>
>if m.lPrivate = .t.
>    wait wind 'Private ok'
>else
>    wait wind 'Private not ok'
>endif
>
>
>function form_call
>    create cursor test ( lLocal L, lPrivate L , lPublic L )
>    append blank
>    scatter memvar
>
>
>

>
>
>Even If we leave aside code purity & speed for the moment
>we still hv problem!
>Code flow gets influences from 'outer space'
>without any warning !
>
>I just don't like it :)