Dave,
Personally I am not a fan of the "M." prefix and find it unnecessary.
without the m.Prefix it is impossible to build a generic procedure / application.
Regards,
Koen
2017-08-01 10:25 GMT+02:00 John Weller john@jbweller.force9.co.uk:
+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
[excessive quoting removed by server]