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
-----Original Message----- From: ProFox [mailto:profox-bounces@leafe.com] On Behalf Of mbsoftwaresolutions@mbsoftwaresolutions.com Sent: 01 August 2017 01:17 To: ProFox Email List profox@leafe.com Subject: Re: GETFILE() Returns Empty String in Some Cases
On 2017-07-31 16:04, Ken Dibble wrote:
GAAAAAHHH!!! That's it!!
Not a PRIVATE declaration, the variable is declared LOCAL.
But in application mode there is a field in an open table with the same name as the variable. I applied the "essential m-dot" to the variable, and that fixed it.
That "variable with same name as a field name" has screwed me in the past more than once. That's why I like my "outdated" variable declarations as pcFilename because I definitely don't conflict with MyTable.cFilename. That works for me. Sorry for the purists who see that as horrible. lol
[excessive quoting removed by server]