+1
It's always good to know I use the same methodology as a master. :-)
John Weller 07976 393631 01380 723235 Sent from my iPhone
On 1 Aug 2017, at 08:44, Dave Crozier DaveC@Flexipol.co.uk wrote:
Mike, I agree with reasoning, but I have a slightly different methodology in that all table/database variables AREN'T designated with a type prefix but all programming variables are. This way there is never any confusion as I reckon that the name in a table should only reflect the contents not the data type. If you need to make the data type more obvious then include it in the name i.e:
Start_Date D Is_Live L Customer_Id C(20)
Addressing any of these field in mainline programming then becomes trivial and you can easily do:
Scatter <Table> name oData
dStart_Date = oData.Start_Date
or declare a local/private variable lIs_Live with no fear of messing things up with no confusion.
Personally I am not a fan of the "M." prefix and find it unnecessary.
Just a FWIW.
Dave