>>>The GO TOP is stupid since the scan will start at the top.
>
>Yep, just as SCAN will reselect the correct alias() without the developer having to do it explicitly before ENDSCAN. I've seen both of these redundant practices more than once...

I just cut them out knowing the majority of developers don't know or care it is redundant.

>
>

		IF m.wScanForEndOfDay = 1
>				REPLACE OutForEOD WITH 0 for OutForEOD<>0 in ScanGrL
>			endif
>			SCAN
>				wMessBody = m.wMessBody + CHR(13) + ALLTRIM(STR(OrdNmb))
>			ENDSCAN
>			wnAnswer = MESSAGEBOX(m.wMessBody, 4 + 32 + 256, m.goApp.cCaption)

>
>Makes sense to split out the replace, though fwiw you could probably leave out the "in ScanGrL" since it must be already selected.

I like the IN clause - because it has at least one major operational benefit. That is often my point. It is very clear what is going on both with mdot and with IN clause.

replace alias.fieldname is silly. There is only one time where it is necessary. That is when you have 2 tables related and you are updating columns in both related tables. That's it. Lots of people think it looks better and works better and is somehow safer, but here comes the peanut gallery again.

>
>Other issue would be that the original always replaces OutForEOD with 0 if m.wScanForEndOfDay = 1, which might intentionally affect (for example) a timestamp field or trigger, in which case your version might be better with replace all...

Good point. There are no triggers in this system. There are no transactions, there are no tableupdates. There is a horrible mix of remote views and sqlexecs and is once again a great example of throw crap at the wall and hoping something sticks.

>
>None of that is a snipe obviously. I think we were both there for the mdot flame wars when CamelCase was the answer and mdot was obsolete... till it wasn't. Every so often that happens again in one of these threads and I don't want to miss out!