>

SCAN FOR ordnmb=m.ordlin.ordnmb AND lnline=m.ordlin.lnline

>
>Definitely agree that SCAN FOR is preferable to SET FILTER, SCAN - though sometimes if code is in 3rd-party resources whose next update will overwrite any local edits, or from decades ago before all current features got added to VFP- then it may be rational to declare "if it ain't broke, don't fix it."

No. Never. If it's been broken forever is reason to fix it now. Spending hours to debug code to find why data got trashed and then not be able to plug in transactions, is just dumb.

>
>FWIW, in 2021 and if you ever intend to use VFP C++ Compiler: there's a difference between
>
>

nStyle_Stone_Price=0
>nOrdLin_Var_Price = 0
>nDiamValu = 0
>nClrValu = 0
>nProtected = 0

>
>- and -
>
>

store 0 to nStyle_Stone_Price, nOrdLin_Var_Price, nDiamValu, nClrValu, nProtected

>
>By default, the first version will have the variable names obfuscated; the second will not.
>
>You could cause the second version to obfuscate by including comment attributions:
>
>

* nStyle_Stone_Price=
>* nOrdLin_Var_Price =
>* nDiamValu = 
>* nClrValu = 
>* nProtected =

>
>Just something to think about! ;-) - J