No need to go into a religious war. It is just not worth it :)

I said:
"Number 2, IMO opinion is the most stupid one."

1. IMO, indicates it is my opinion without the authority to state this a fact.
This would have been different if I ommitted the IMO

2. Even the wisest people can make a stupid choice. So, even if IMO I classify your choice of using #2 as a stupid one, it does not say that I classify YOU as stupid. I´ve got too much respect of people like you who made a decision I would not make.

Walter,

>Walter,
>Not going in a religous war - I just didn't like to be classified as stupid:)
>Cetin
>
>>Hi Fabio,
>>
>>>>Well, as Calvin has pointed out, if you prefix your memory accesses with m., pronounced "uhmm", things will happen faster. Seems contradictory, but uhm, who am I to say.
>>>
>>>Calvin say that to put m. prefix it is a faster option,
>>>I say that who uses a memvar without a prefixed one of m. he makes a program error.
>>>
>>>The difference is substantial.
>>
>>Again, it seems a rather religious thing. M. does avoid VFPs confusion whether it references a field or memory variable and has an advantage over not using it when a table with large number of fields selected. Nothing new here. Calvins explanation of the internals are nice, but really add nothing news here.
>>
>>However,
>>1. some religions, say never to use it, because it makes your code ugly.
>>2. some religions, say use it only when there can be confusion between variables and fiels
>>3. some religions, say always use it, even with objects, THISFORM, etc.
>>
>>Number 2, IMO opinion is the most stupid one. Heaving to learn a lot of rules when to use it or not (See wiki topic, often to do with VFPs internal behaviour) is nonproductive. It probably is more an idealism than anyone could possible stick to without making errors in this. Even though, people are trying to force this down our throat.
>>
>>Number 3, is an interesting one, you practise yourself. Trying to stick religiously to using m. and only omitting it in cases where you can´t use it (e.g. macros). I doubt if there are many people doing this so strict, but from a logical point of view, I must admit, you either do it, or not. It is not my personal preference though.
>>
>>Number 1, my favourate lets me keep writing code without the ugly use of m. and only in rare occasions where I cannot be sure of having a field name in a selected table, I´ll use the m. argument. As for the speed argument, it really only is applicable in long CPU intensive jobs where a large field count table is selected. I´d have difficulty in naming one case I´ve ever programmed in my carreer.
>>
>>Bottom line, you can write good and solid code with or without using m. . No matter the argument you´re not going to convince the well experienced VFP developper to change his standpoint on this. It is non productive.
>>
>>My 0.02 eurocents