Thanks for the input Rick!

>Why would you WANT something like that unless you're building a seperate business layer in a different language (like C#) altogether?

Yes thats exactly why. But also because unless we use ADO which I understand Microsoft is deprecating, we would be stuck installing SQL Servers on all our clients servers and virtual servers. But if we use .NET as a middle tier we can access the SQL data via ADO.NET and call this method from either VFP (front end) or Classic ASP (web front end).

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

Yeah, unfortunately we don't have the resources to do a full conversion. Building a hybrid product is not my first choice but it would allow us to migrate our systems in chunks with our client's history tables (reaching 2 gig limits) being the reasonable first choice.

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

We are looking into SQL licensing to try to factor what difference in cost we may be looking at. Since we offer our clients SaaS models with data warehousing, we are looking a numerous servers and virtual servers we would have to install SQL Server on to allow straight ODBC connections (unless Microsoft is coming out with ODBC.NET anytime soon? :)

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

Yeah, I will check those out. I've alway been impressed with what you've done Rick. Do any of your tools use ADO.NET as a middle tier between VFP and SQL ?

Thanks!