>But we were discussing the SCAN construct. You claim that it's better to code SELECT &lcAlias just before the ENDSCAN, as a workaround, because the Fox is unreliable there. I challenged that. It is simply not true and there is no need for this 'workaround'.

Indeed. The number of lines of code or years of experience is no justification for doing anything. People who smoke for 20 year and have consumed 36,500 cigarettes cannot argue that they're doing a good thing for themselves and those around them. Although it's clearly their choice.

>
>>I dare say that after our 100 plus classes, 500,000+ lines of code, and an 85 table database in a 15 year old enteprise package that started in the DOS days we have written enough code that makes fox strain and have seen many anamolies that we not the result of "wrong code". We do not note most of them and merely code around them and move on to generating reveneue. We pride ourselves in making fox do things it was not meant to do especially in our UI and have a very complex application by Fox standards. Example, we have a dynamic field generator that allows users add columns ( of any datatype ) to tables and in a future version add tables ( and their children ) and we will handle it without adding code.
>>
>>We will continue to code around them as an ounce of prevention is worth a pound of cure. Our package is maturing and is now 90% data driven and so abstract we can modify the database structure without changing the code. Most of our code is so abstract that without the code comments and design docs we would not remember what it does only a few months after writing it.
>>
>>Example of bad behavior, relations in tables stunk in VFP 6 and constantly got broken and made our grids ( we have 21 of them ) hose up. We are still gun shy even in Fox 9 and have dropped all relations and use views ( soon to be CursorAdapters ) only in the grids.
>>
>>Over then next several years we are carving off isolated pieces of our code ( first is the report display engine going to a C# tool ) and converting distinct modules to C# and hooking to SQL. Our clients in the market we solicit to is driving us away from Fox. We intend to be fully converted by 2008 or 2009.