> Agree totally! If we as a VFPers develop our apps using the "design ideas" of n-tier approach, even in our VFP-only type of apps, we should be one-step closer when the time comes to actually "physically" separate a layer to handle access from other clients, etc.

Yep. The problem is that VFP developers have to be willing to sacrifice a number of things that they take for granted in order to accomplish it. Here's a top x (I don't know how many I'll have yet) list of things you can't use.

1. Grids (actually, there are some ways to use grids, but they'd basically be very VFP specific and slow.)
2. The Data Environment
3. Binding Directly to Fields
4. The Report Writer (at least to directly print reports from the front-end.)
5. Direct calls to WAIT WINDOW, MESSAGEBOX(), etc. in the enforcement of your business rules.
6. The DML in the UI tier. That's right, no REPLACES, SELECTs, SQL, etc. in the UI tier. All of that has to take place somewhere else.
7. Comboboxes & Listboxes with a RowSource type of fields, alias, SQL statement or query.

I'm sure there's more, but you get the idea.

Moving all of the code that actually does data manipulation out of the UI tier isn't that big of a deal, data binding is still the toughest IMO. There may be other options but your basic choices are ADO, SCATTER NAME, business object properties, SetField & GetField methods at the business object level, arrays and/or a field object. I suppose memory variables are also an option. Switching to any of these mechanisms is not trivial if you're used to working with the native DE and binding directly to fields.