Hi David.

>I don't really see how it offers an advantage over ODBC/SQL if you're using external data. It seems less "databasey" to me. This is probably my naivite, but to me, it doesn't get much easier than ODBC combined with SQL, and I can easily bind my results to grids (which I don't use often, but still, the need is there).

Here's my $0.02 on this point. If you're doing n-tier, you have to forget about cursors. Since you can't pass a cursor to anything outside the current VFP session, you end up having to constantly package and unpackage cursors to pass them between the layers. So, while ODBC works fine in a two-tier environment, it won't in an n-tier one.

Instead, use a mechanism that provides platform-independent data passing. ADO is one choice, XML is another. Yes, this means unpackaging the data into a VFP cursor if you want to display the data in a VFP Grid, but as Craig pointed out, you can bind an ADO RecordSet to the MSFlexGrid and use it instead.

BTW, Mike Helland has a valid point: you can still use an n-tier design and package the components into a single EXE. Why would you want to do this? For the future. What if one day you decide to use a different data store than VFP tables? What if you want to expose some or all of the app's functionality over the Internet? What if another tool (a VB app or component, or even just Excel) needs access to your business logic? It's way easier to unpackage the EXE and build COM DLLs if the design is already n-tier than it is to redo the app from scratch because it uses a 2-tier design. Some frameworks (such as Visual FoxExpress and Mere Mortals) make this very easy to do; you just tell the class factory (which is responsible for instantiating all classes used by the app) that instead of instantiating a VFP class, now it has to instantiate a COM object.

Hope this helps.

Doug