Hi Kevin,

Why would you WANT something like that unless you're building a seperate business layer in a different language (like C#) altogether? You can definitely do that, *if* you want to build your business logic in something else like .NET. But that begs the question - if you do why not build the whole app that way in the first place? Mixing VFP with .NET or COM is not an optimal way to develop unless there's a real good reason to do so (like accessing functionality that doesn't otherwise exist).

ODBC is a low level data access layer - it's fast and gives direct access to the underlying data drivers, so this is a good choice for VFP apps that need to access SQL Server data. You can build your data layer in VFP if you need higher level of abstraction.

You might look at wwSQL (which is a SQL wrapper that handles managing connections and provides some abstractions for error handling etc.) and wwBusiness (part of West Wind Client Tools, which in turn uses wwSQL to provide a higher level business layer. Many other solutions for VFP exist along those same lines - any of the major frameworks like Mere Mortals, Fox Express, Visual MaxFrame etc. all provide similar abstractions inside of VFP whcih is much more efficient than external COM servers to provide similar functionality.

Hope this helps,

+++ Rick ---


>>> In your middle tier you still will be using one of the two techniques (if middle tier is VFP class library) - Cursor Adapter or plain SQLExec commands.
>
>
>Yeah I was thinking something like
>
>

>VFP <-- -->  .NET (COM) <-- -->  SQL
>

>
>Not sure if that is feasible or if it would solve ODBC issue and allow for different connection options....
>
>Thanks!