>>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 don't design and write systems that expose an entire domain to the possibility of modification by the end user. I've yet to see a situation where the end-user wanted to interactively operate on the entire domain of a large dataset. I avoid assumptions about exactly how the data will be retrieved, so that getting the data needed to do what the user wants is as easy and flexible as I can make it. If I use a native VFP DBC, then I have tags out the wazoo, p-views, a temporary DBC that can be used to create new views on the fly without grunging up my app's DBC, I make indexes on thing I pull out.

When I move to C/S, then what goes on remains very similar, if not the same. I still use a temporary DBC to create views. I'm probably going to change some of the things I do to use SPT. Transaction management is going to change. A lot of the work stays the way it was when I did it using the native capabilities; remote views often replace p-views on a one-for-one basis, and the change doesn't affect the things that relied on the local views much.

Lookup tables, local user preferences, things that aren't a part of the central application database tend to stay native. I like being able to configure things without having to get the backend involved, and there's rarely a compelling reason to move these things into the backend environment. I even use the registry to point to where things ought to be located to get started up.

Excuse me, should we be questioning my knowledge of the Win32 environment here? Network security? User and system configuration processes? Maybe where the power switch is on the box? I'm sure you understand these things infinitely better than I do...care to expound on where configuration and installation things need to be stored? The right way to figure out where system tools can be found? What systems services are available? Perhaps I just don't know anything at all about the Windows application environment. Or do I just not know anything about VFP and data-centric applications?

I'm sure that, if nothing else, my choice of colors for my text is just awful. You're entitled to that opinion.