>>>In any project you'll have to explain/develop conventions.Forcing to use mdot is just as well an example of that. For fieldnames, using the three letter prefix has NOT been motivated by the var/field conflicts, but rather with the bonus that each fieldname is unique in your database. Therefore if you encounter a fieldname anywhere in SQL statements and elsewhere in your code, you know immediately where it orginates from. In SQL it will reduce the number of times to prefix fields with an alias to make clear from which table the field comes from ANYWHERE in your code.
>>
>>Of course, the big disadvantage of your naming convention is that you're giving up 4 (not 3) of the 10 characters you have to name a field, meaning that you have to find a meaningful description of the field in just 6 characters.
>>
>>
>>On the readability question, when I finally bit the bullet (after being bitten too many times) and switched to using mdot, it took only a few hours before it became second nature and easily readable. It wasn't a whole lot different than adapting to IntelliSense. I've heard people say they turn off IntelliSense because it gets in their way, but I can help believing that for most of them, a few hours working with it on would solve that problem.
>>
>>Tamar
>
>Hi Tamar,
>IMHO using such a convention the issue is much more serious than giving up a few letters (and weren't they complaining 2 characters m. rendering readability?). When you use 3-4 chars (unnecessary) prefix you make the fieldnames unique within a database. That sounds to be a good thing? Probably not. We are not all using the native VFP tables nor VFP only tools. Within VFP it sounds be good just because (oh well for what?). In other databases and their tools, the case is different. Some tools simply utilize the fact that same named fields are the best candidates for join keys. Having unique names:
>
>

select * from tableA join tableB ...

>
>you wouldn't bother about fieldnames? Right, maybe, but afterall "select *" is not a recommended syntax anyway.
>
>Hard to understand why would I ever want to name a field ord_OrderDate (maybe helping to prevent cus_OrderDate?) Ugly and readable, go figure. They surely help unnecessarily typing 3-4 more letters per fieldname.

Cetin,

Is it really you? I would not expect such an reply from you. I'd thought you knew better.

First of all, I can't remember the time I worked with FOX2X or FREE tables which have a 10 character issue. Fields coming from SQL server and from tables in a DBC do not have such issue so it is not an issue at all. Really if we are talking about development where we are still bound to 10 characters I think the is no discussion possible: I can't see why anyone would still go that route.

As for your argument about mdot and the three character Prefix. That one is very easy. The mdot does not carry any information about the variable to me. The three letter prefix does carry very important information namely from which table it comes from.

Consider you have a doctors table and a patient table.
Both would have a column 'Name'

if you have a query to list patients and their doctors your SQL will have rename the columns to avoid ambiguity.
You don't have to do this in my case because the columns would have different names: PAT_NAME and DOC_NAME . There could be no confusion where this field comes from anywhere in you code, whether VFP or SQL querys because the name of the field is unique in the database. This adds to the readability of your code, not having to guess what the field 'Name' refers to.

>Hard to understand why would I ever want to name a field ord_OrderDate (maybe helping to prevent cus_OrderDate?) Ugly and readable, go figure. They surely help unnecessarily typing 3-4 more letters per fieldname.

The field would just be named: ORD_DATE not ORD_ORDERDATE. The prefix tells you the identity of the table so no need to repeat that in the rest of the column name.

Other implications:

Each table will have a PK field fromatted as XXX_PK and foreign keys can be formated as CCC_PPPFK (C= Child prefix table, P = Parent prefix table), so

ORD_CUSFK = Forgeign key from the orders table to the customers table
PAT_DOCFK = Reference to the patients doctor

It makes it very clear, also in code, what this field means and what it refers to. Als long as there are duplicate fields no self join in the query, there is no need to rename fields when having a naming conflict and therefore all the fields referenced in code are having the same name as the fields where they originate from. A huge bonus as no matter what code I look at, the fieldname always is going to tell me what it is and where it comes from.

And if not using GUIDS or IDENTITY columns but relying on a number generator you can use the fieldname you're generating a number for as a key, as it is unique.
If you want to store metadata of fields for the purpose of validation, capitlisation, formatting etc you can do so by simply taking the fieldname regardless under which alias the view or table is opened.
And there are other advantages we created on having a unique fieldname in the database, like creating ad-hoc updatable views where we can use a hint like 'ORD_*' to indicate that only all fieldname beginning with ORD_ are to be updatable, audit trail functionality etc.

I began using this naming convention suggested to me about 20 years ago and never looked back. I cannot find any reason to do so, esspecially when having databases with large number of tables.
Several big companies use this or simular naming convention (e.g. wikipedia) so this is not a quirk that is rare. See https://www.codeproject.com/Articles/22947/A-Naming-Scheme-for-Database-Tables-and-Fields for more arguments.

Like all naming convention discussion, this for a significant part has to do with unfamiliarity and personal preference, and too often fall in the category 'holy wars'