Walter,

I appreciate the fact that you've qualified some of your responses. Yes, I agree, many VFP apps use this and other things that are characteristic of the monolithic model.

However, it's not necessary and generally not recommended. In the world of acquisitions and buy-outs, even things developed for a 'mom and pop' application may need to scale someday.

I certainly don't claim any awareness of what markets are like in your neck of the woods, but in my general area (and for developers I talk to), following a 'mom and pop' model is not enough to sustain and grow a software consulting practice.

I'm encountering it right now - a job costing system I wrote last year for a small construction outfit is now being evaluated by a larger company. When I wrote the app last year, I used a basic but functional three-tier model. I was able to do a quick demo to demonstrate that this seemingly 'desktop' app could be run using either web services or remoting, without any code changes.

While this application does not have the reporting requirements necessary for the larger company, they're still interested because it supports a distributed model "out of the box. Several years ago, when functionality was all that mattered to many, the app wouldn't have stood a chance. However, the last several years have seen a bit of a shift where scalable architecture receives more emphasis than before. (Don't get me wrong, rich functionality is still critical).

As I said in a prior post, in .NET one can define a business object with table props and a GetData Method with a condition, and bind the results to a datagrid...as easily as it can be done in VFP.

So for a .NET developer who is thinking ahead about a distributed model, even if the current implementation is no more involved than a LAN, the lack of binding to a table that was directly opened with a USE is a non-issue.

This gets into the concept that's been mentioned before about "tactical vs. strategic".

Kevin