>>>>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'

That is true, naming conventions are what they are, conventions, and as such they are very personal and preferential. They do not have any direct influence on the product itself. I too started to use a two letter prefix to field names 20 years ago and I never looked back, because it made coding so much more efficient for me. One example:
Because field names may not be unique in other projects, I had to write queries such as
SELECT Employees.BirthDate AS Em_Birthdate, Spouse.BirthDate AS Sp_BirthDate from Employees JOIN Spouse...
So there you end up getting an ugly prefix that you did not want in the first place, and worse, this prefix has not been defined in the initial table structure and can even be different per query.
I used to write code snippets for queries and data objects, based on having knowledge of the field names, but when the field names need an alias, then those code snippets would not work because the field names could change arbitrarily in the code.

However I try keeping field names at 10 characters maximum, because even though you can use longer names in SQL Server without problem, sometimes you need to set an index on a view to make it sortable, and index tag names can only be 10 characters long. So when creating longer field names I quickly ran into the problem that the index tag had to be different from the original field name, which needed some ugly exception code to be used.