>HI Craig,
>
>>>You mean code that should work with any database table with tables than can have any names in there ?
>
>>How about the situation where you inherit an existing application/database.
>
>I guess, you've got me here. Fortunately I don't often deal with this kind of stuff. However even if this is the case it depends on having different naming conventions of fields and variables, because I don't expect fields to follow the same naming convention as variables.
>
>Sure if I come accross such project where I indeed have to deal with someone else his database, I might want to decide to use m. for that project exclusively.
>
>However this discussion about m. has triggered me to think about it more closely. I see advantages but also disadvantages.

I wish you'd tell us what disadvantages you see. Readability is not a significant argument.

>
>>>I'm not sure what kind of programs you're are talking about then. As I stated before I avoid the situation where I can have fields and variables with the same name by having a three character prefix plus an underscore for the fieldname. For variable I always begin with a one char type prefix.
>
>>You're probably in the minority doing this. Everyone I've talked to about this in the past five years doesn't do it.
>
>Might be, I don't know. I'm highly comfortable in doing this. It ensures that every field in the database is unique, which has it advantages in writing SQL commands with joins, but also in SQL results (like in views) in inmediately recognizing which table a field comes from. It also has a big advantage if you write an export program (like a mailmerge) where the user can pick its fields to export, so you avoid having to fiels (e.g. Name in patients table and Name in doctors table) to be the same.
>

Drew Speedie's field naming conventions (which I use BTW) are similar. I think Craig was referring to your variable naming since you seem to not be using Hungarian notation.