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

Again, agree. IMHO, one of the toughest aspect to learn and implement is moving away from handling large volumnes of data. In traditional VFP-only apps (non-client/server), we have been spoiled by having data readily available whenever we need them. The n-tier design, again IMHO, isn't very good at working with volumes of data at a time. It's more tuned for working with small sets of data (even smaller than client/server).

If an app has to manipulate larger sets of data, I see only ADO as the workable alternative. And yes, no matter what M$ says, it is NOT currently trivial.