>>>>>IOW, there's no compelling reason not to design with scalability and maintainability in mind up front.
>>>>
>>>>Maintainability and scalability are quite different options. I would prefer to stay on reality ground. When you finish a system client expects to use this system for 4-5 or more years, with minimum maintenance efforts and no major changes. When this period (5 or more yrs) over the system will be dumped and rewritten from scratch, and nobody knows what language, archotecture or anything else will be used after this long period of time. This is how things live in real world. It does not fit to theoretical model? Sorry, but this is imperfect world.
>>>>You dido notes to your experience, well it's your experience. However, the voluntary resignation of using indexes is way beoynd common sense. This discussion obviously carries semantic flavour. In old days when cursing was not the main business on this forum, the sides would just say that this is question of individual preferences and say good night. I do not expect this now.
>>>
>>>OK, let's get to it. Are you saying that I have no experience developing outside of the C/S environment? That I've never used a C/S environment? I know, I've never written or maintained a system. Perhaps I know nothing of VFP, either. Let's be specific about how, where and when I don't know about design and implementation.
>>
>>I have never said that you don't have experience outside C/S. Calm down, please. That's exactly what I said: it's become normal on this forus to flame and burn out. This relates to all stuff below. Nobody argues your skills or qualifications. I said "it's your experience" in positive sense. That's just local environment that makes everything to be perceived as controversial and offensive.
>
>I apologize for misinterpreting your statement. Can you explain how better maintainability can be achieved through the use of the native xBASE command set rather than the SQL environment? I'm especially interested in knowing how a detailed, procedural approach to data set identication and operations are easier to maintain and adapt over time than the use of SQL and p-view operations for similar purposes, especially since it seems that to me that the SQL code is simpler and clearer to write and understand.

First of all, let's decide that this is not detailed procedural approach, ok?
The maintainability usually means that all minor changes to a system can be done simply enough. SImplicity here usually means that application design allows to make these changes seamlessly. This, in its turn, usually goes to OO-design of the application. IMO, changing of data engine cannot be considered as minor change and should not be included into maintainablity notion. Do you agree with this? I use the word 'usually' because it's really elastic definition.