>>dDuedate why not DueDate?
>
>why not just dDue?
>
>>cCity, cSt, cZip, cPhone, cCell
>>
>>It's just a waste of a character.
>>
>
>Not really, you could use a numeric code for a city, I wouldn't, and I know I wouldn't, but there's no guarantee of that, and besides what if someone other than the author is reading the code, should he just assume things?.
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.
>>Does anyone ever do a Public anymore? If not why should I disclose that everything is local.
>
>
>It's helped me give a variable the same name as a field for calculation purposes, with the difference of the scope specifier, and long gone are the days where I got my vars and fields mixed up.
Oh well mixing stuff up is tough. Been there and done that. I even purchased an error correcting modem but to no avail. ;-)
>
>>Now If a comapny set standards like table filed names have the first 2 digits defining the table they reference, that would be somthing I would agree with.
>>
>>SHordnum = Sales Header order #
>>SDlineno = Sales Detail line #
>>SDqtyord = Sales Detail Qyt ordered
>>SD_ID = Sales header Primary Key
>>SD_SHK = Key to Sales header
>>SH_CUK = Key to customer table
>>
>>Now in a join my primary keys are unique in name and that is something that is usefull.
>>
>>Where in the example below:
>>Sele Cust.iid, customer.cCompany, SOHeader.iid ..... ;
>>from VES!Cust inner join VES!SOHEADER ;
>>ON Cust.iid = SOheader.iid ;
>>where ... ;
>>This will always give iid_a, iid_b in a return set and it's a RPITA to adapt the rightful keys to the proper tables in a view.
>
>I had a coworker who did that and I surely didn't like it, just knowing the table name is enough to me, I had to keep looking up field names while writing code, there's no telling how he'd abbreviate the table name.
>
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.
>I see it like property names, same properties have the exact same names in different classes and objects. It's just simpler to remember the name like that, IMO.
>
>Also having the same name across tables has made it easier to write generic code in some classes. As far as SELECTS you can use the AS clause to give the field a distinctive name.
I use views. Having all keys ID is not a good idea. It's bad programming to rely on an "as" clause in the select stament and then have to go to the dbsetprop and do this.
* 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.
