>>>Since we are unable to search for strings with less than 3 characters could someone give me some references or information on the advantages/disadvantages in using m. with variable names as opposed to not using it? I think I've heard discussions regarding performance, but couldn't locate any. Our manager wants to elimiate all notation on variables - and in some ways I agree with regards to readability - but he would like to remove the m. convention as well. We believe that there may be issues related to this and it's been put upon me to find out what the deal is.
>>>
>>>UPDATE: I have no idea why I wasn't given a notice that there was a problem with the title of this thread - it just truncated it instead of asking me to fix it - but it should have read along the lines of PERFORMANE USING M DOT. Could someone from UT please fix this?
>>
>>I forgot to mention one thing. Another convention that he believes would resolve any conflicts between non-notated variables and field names is simply by adding the table alias to all field references. This sounds reasonable, but again I haven't found any good discussion on this point.
>
>On the other hand, the possible confusion between object.property and alias.field names could be used for testing purposes. I used this several times myself in testing by subsituting non-existent object with the fake table having the same name/fields as the object/properties and vice versa.

Since David Frankenbach wrote about that on the Wiki, I'm still not sure I could recommend that practice. If you need to test an object, using a cursor to simulate the object's properties is potentially terribly misleading. If there is an access method on one of the properties of the actual object, that may invalidate any testing you're doing without the object. Is it so hard to instantiate the object you need to test? Maybe it would be better to extend the object to make it easier to test?