>>Al last I understand what you want to say. Really, nobody drop self into trouble of handling large number of tires at once, you're right here. However, I'm saying about a system with as little tires as possible to START development of the large n-tire system. After development of the BASE (say, standard for THAT application only), other developers using that base interfaces can enhance system by other tires. These other developers do not require to know the entire system, just what format of XML file they should send to the system (for example). However, to make it such simple, you require a BASE anyway, and development of such base require really carefull planning and understanding for all tires o fthe base at once to predict any problems. Otherwise system will cost too much money in the future for maintenance and enhancements, because each new tire will require to modify also other tires, that is tremendous thing, indeed.
>>
>
>I agree that one has to do it that way. However if you decide later you need to split layers then you will have to understand the application. If the business layer is written in VFP and directly used the tables with SEEK etc. then you will have to rewrite it when you go to a three tier approach. The best you can do in that case is try to use SQL and try to compartmentalize the data access into separate methods.
>

I meant building basic tires from start, not building a signe-tire application from start. I meant building a 3 or 4-tire base and then expand it to more tires.

>>
>>>
>>I agree and disagree. With n-tire approach you require more thinking and ORGANIZING, because the PURPOSE of n-tire is to make system FLEXIBLE, nad thus you have more ways to do something and more space for thinking and experimenting different approaches. 2-tire application (pure Client/Server with SQLEXEC() as you sampled) is MUCH more easy and quick to make, hense the problems are all known and not hard to eliminate. The problems will happen much LATER, when customer will want to enhance the application or system, add new components, users, platforms etc. - that is a prolem for 2-tire application.
>
>The example I described was not 2-tier in my opinion, even though it was "client/server" but 1-tier. If the 1st tier has to know the details of the operation of the second tier it's not a 2-tier IMHO. Certainly other people disagree! Which I respect! A two tier system would be, for example, the same application using views. In that case the form (the UI) does not have to understand the details of SQL Server. That is contained in the database container instead.
>
>I don't think I'm splitting hairs here. I think many people found VFP forms very hard. You still always see a million Grid questions. Including SQL passthrough logic in a program makes it more complicated to write than if access to Server is abstracted. And complicated programs take longer to write and are more buggy. Ideally, you should not have to think about SQL Server at the same time as having to get a grid to work. My approach is to create the interface (e.g. messaging objects) between the different layers and worry about non VFP implementations later.
>

The interface is not an issue. Try to do in VB all these things you have in VFP, and you will spend MUCH more time. VFP just give more tools for interface development, so it also cause a lot more questions ;) There are also a frameworks that make a task of making a simple 1 or 2-tire application very quick and with very good quality of interface.

>For example a normal VFP object (non-COM) can be used to send information from the VFP business logic to the VFP Form. This works fine until you use some other UI or business logic. At that point you can turn the VFP message object into a COM object. Even if you switch to something completely different you are in a lot better position because the programs are organized properly already. And maybe your VFP message object has to have an XML string attached to it, but that won't change the business objects or the user interface that manipulates it.
>

I agree here. However, to predict all cases of use of such COM object, you require to develope the INTERFACE of that COM object, so any other UI applications will be able to use that COM object. And to predict all these cases you require to spend a lot of time, that will have pay off in the future because no need to change or redesign that COM object. This development of a simple 3-tire application is MUCH more complex and time-consuming task, however, the time and resources spent will quickly be returned in the future in long term.