Hi Walter,

To be honest, I am getting more and more tired of reading your messages. You may be a guru in your own eyes, but in my eyes you are nothing but a nagging (wo)man. Do you really mean that we should use m.this and m.thisform in stead of this and thisform? Oh, please, take a aspirin or two, or take a whole box. Simply because you can walk in the middle of the road at night, does not necessarily mean that you should recommend other people to walk there at all times? The logic is EXACTLY the same!

>David,
>
>>In the tens of thousands of lines that I've written in VFP since VFP3 shipped I have never once needed to use m.this or m.thisform.
>
>I really get irritated by such statements. If you did not need it for somereason does not mean anything to another person. If that person has to deal with a table with such name (beyond control), he/she might no have another choice. Another reason might be the performance advantage the mdot seems to have when a table with a large number of fields are open.
>
>I've litterly written hundreds of thousands lines of VFP code, but I still might not encounter a situation which you might use as an argument to code differently. These types of statement IMO show a kind of arrogance that should be banned from the UT.
>
>>If you don't have control over your development environment to forbid the use of a table/cursor name of this, thisform or thisformset then that's more a problem with your environment than it is with the VFP language itself.
>
>Very strange argument. So when upgrading from or interfacing with Fox2.x, possibly dbase or clipper in which these names are not a problem, it still is a problem of the environment. Are you going to tell the client this ??
>
>>You are free to continue using m.this. You are also free to continue to experience the random C05 errors that m.this causes. Your position on the matter is a rather silly high horse to sit on, considering that a C05 is quite likely to cause table and index corruption in addition to your end users losing the work they are trying to get done.
>
>The C5 errors should be solved by the VFPT, period. We are free to list those BUGs and expect the VFPT to look at it. It is eventually the decision of the VFPT to fix it, not yours.
>
>Walter,