>You can use ODBC in .Net to talk to SQL Server, but ADO.Net will give you better performance and memory management. But using COM, you'll lose some performance on the VFP side. I'm just not clear on why you don't use ODBC for the VFP components and ADO.Net for the .Net components.
>You also say "ASP", but I assume you mean ASP.Net

No, unfortunately I mean classic ASP, which is what our website front end is written in. We are eventually going to move this to asp.net but are not at that point yet.

On the VFP side everything is written in straight native VFP, no ODBC. Because some of our clients are hitting the 2 gig limit on their history tables, we want to move these to SQL but we don't have the time or money to do a full conversion of our system. So we are looking at doing JUST the history tables and keeping the main tables native VFP. We ALSO have different history tables on our web side that we also want to move to SQL. These will be accessed BOTH by classic ASP and VFP COM.

The reason we are thinking about building a .NET middle tier COM is that this would be able to be called by VFP or Classic ASP and it could be called from anywhere. If we went straight ODBC, we would be stuck installing SQL on every server (and virtual server) since we data warehouse most of our clients, whereas if we built an .NET COM that uses ADO.NET instead of ODBC, we feel that this would allow us the flexibility to have one or two main SQL servers that we would need to access. It would also START us to moving our business logic to a middle tier and we can stick our toe in the migration pool. Also, we are going to be doing some benchmarks to see how ODBC and ADO.NET perform. Our guess is that ADO.NET will be much, much faster on large databases.