>As a preference... in your field names... do you include the type as part of the description...? even if you are using Hungarian notation...? such as...
>
>tstarttime vs tstart
>dduedate vs ddue

When starting a new application I/we decide on the field naming convention to use for the dataset of that application. One model is dxxx_freetext.

The first character denotes the datatype, and the next three characters uniquely identify the table. This three-character section could be referred to as the table descriptor. Thus, any field name conflicts in views and sql-select statements are effectively prevented, and you're also told what table a field in a view or cursor originated from. An underscore is used to ease the reading of the field descriptor on the right. Certain fields have special field descriptors. In the model, all primary keys have "PK" as the field descriptor, for example iadr_pk. The field descriptor of a foreign key field is determined by the table descriptor of the linked table, followed by an underscore, followed by "FK", for example iwhn_adr_fk. That's all for fields.

Names like dDueDate are overkill. When a colleague writes that and you are the reviewer, correct him on this one and let him change it to dDue.

As you have seen, many do not use a datatype character. I understand some of their reasoning. They don't see the advantage of the c in cUserName. Sure, there's no obvious advantage there, but other times there is a clear advantage. The model cannot (should not) be applied to only a part of the fields. The advantage outweighs the irrelevant cases, IMO.

However, there is one type of problem that datatype prefixes cause. If it is decided afterwards that the datatype must change, one has to change all occurrences in the tables and the code also. I can live with that.