Hi kevin,

>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.

We all know that working with (VFP SQL) views in VFP is the preffered way of developping your application in a fashion that it is less a problem when the day comes you'll have to upsize the project.

However, sometimes at forehand you'll know that your application does not have to scale, and every attempt you do to make it scale is a waste of time. I've got a few applications that are used in the field on a laptop, no LAN connection, No other users etc. Just an application that is developped for use by the WHO and currently used in three continents.

>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.

Again it depends on the nature of the application. If there is a potential that the application is going to be multi user in a network and there is a potential for growth then I agree. However, I've got a few applications running where flexibility, ease of use, maintainability and price are far and far more important than a requirement of upsizing this to a SQL server database.

OTOH, I've got a few applications where this is far more important. For example an application meant for human reproduction techniques that will be used in 4 or 5 continents where the customers are either small private clinics or very big academical hospitals simply needs to be scalable.

However, I always am suspicious when people draw the scalability argument. As a designer you've got a pretty good idea which areas of your system have to scale and which don't. Dismissing a combobox for a lookup table, because 'it does not scale' is a very dumb argument. We all know that if the combobox was ment for selecting a state in the USA, it simply does not have to scale. Then number won't exceed the critical number.

>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.

More or less the same happened to me. We wrote a personel system for dutch jails. About a few dozen application have been sold (VFP, not SQL server). Now we are working on a project to install it at every dutch jail. SQL server was never an issue here since they're in a process of centralizing lots of applications on a Citrix farm. Though they don't care about the SQL server version, it is not difficult to implement since 95% already is based on local views. It does not take much to make it C/S if required.

>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.

I'm no expert in this area, and you will know much more about it than I do, but it still sounds to me you have to do a lot of pre-work in order to make it a snap.

>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".

I'm not sure what you mean by that...

Walter,