>Well I would consult that good old data dictionary for all of this mess and not expect to waste a character about the type. Or I could open the DBC.

But it's oh so much nicer and efficient to just have the name tell you all.

>It's a RPITA to remember the name but once you get them down it's a snap. Just like learning what tables control what. Have you ever worked with a true normalized database? Addresses are a table, communications #'s are a table , city, state & zip are a table. This is a pain in the neck too, but it's normalized to the 5th level. I hated working with it but in that situation it was necessary.

Still some level of naming convention is required, even if you don't like using it for the type (some say it takes away abstraction), it's useful to indicate functionality. At the very least I expect consistency in variable names, but then again that's just me.

>
>* Props for the LV_MASTER2.key1 field.
>DBSetProp('LV_MASTER2.key1', 'Field', 'KeyField', .T.)
>DBSetProp('LV_MASTER2.key1', 'Field', 'Updatable', .F.)
>DBSetProp('LV_MASTER2.key1', 'Field', 'UpdateName', 'master2.uid')
>DBSetProp('LV_MASTER2.key1', 'Field', 'DataType', "I")
>
>When you do joins and getting the proper key to control the update for one of the tables gets tricky.
>
>To me this is a standard that is well worth upholding.

I haven't dealth with very complex scenarios as far as views go, still I've faced the problem to a certain level, but you're right, making PK names unique across the database seems like a good idea, I'm still not too sure about the other non-key fields.