Thanks for responding, Doug.

I see your point. I use VFP almost exclusively (a C routine here and there), so I haven't yet encountered a real need to use ADO, which is probably why it didn't make sense to me.

Instead I take the all-in-one approach. Since starting to study OOP books a year ago, I've been playing around with multi-tiered exe's, ala Mike Helland. After much frustration during the learning curve, I have them working very well and very interchangeable. I haven't been doing COM just for the reason's you mentioned - I need my cursors! Instead, I just snap my business and data libraries in and out of apps as needed, and compile them all together. It really works great.

Another reluctance of mine with regards to ADO is I sometimes feel trapped being so MS dependent (which I know I can't avoid). I'd much prefer a more universal strategy, which I think XML provides. ADO has platform restrictions which obviously XML doesn't, and I do need to communicate, at times, with other platforms. I will certainly spend some energy becoming more XML proficient.

Thanks again for responding. Loved your latest FoxTalk piece, and I look forward to the Code article, too!

David

>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