>>>That is right. If you inherit a system where those rules were applied and a rewrite isn't an option, applying mdot is the only reasonable thing left to do. But its an ill advice to start building a new system using the same naming conventions for fields and variables, force the use of mdot and rely on old relics like scatter memvar.
>>
>>As I mentioned rhetoric replying to Mike, I consider grouping mDot usage together with /at same level as "scatter memvar" as unworthy rhetoric.
>
>How so? as this was the common way to do things in Fox2.x. In fact scatter name was not added to the language before VFP6.

"Scatter memvar" is obsolete, mDot is not. Even in FPD / FPW I realized the brittleness introduced via scatter memvar and built my very first fox fwk for various own stuff, tasks and tables up to bookkeeping, scheduling and price forecasts based on Bob Grommes (?) books which had / allowed for "record buffering" via scatter to array. Added some tweaks and dodads to allow record based edit, valid, try_2_save, record_validate, save pattern with array names generated according to table names and field name offsets while sporting common record. Those screens worked with a common "record movement" button set plus edit/save and help offering VCR buttons for different speeds (sometimes tweakable by user if jump size based on record# was not welcome).

Scatter Name is not totally obsolete, but fallback pattern if there are reasons a table buffered cursor is not enough - but the idea of scatter memvar in vfp ***is*** obsolete.

mDot not for read access still necessary if ANY code by others might run inside your app - and even using Hungarian naming I stay with the belt&suspender approach of mDot for read access.

Those 2 are not in the same league - mDot today is still more important than "scatter name" is.

While beauty is in eye of beholder, mDot is more than safety and speed.

regards
thomas