>2. I really want the VFP back end to maintain a lot of state information between calls from the ASP.NET front end, so it doesn't have to go out to SQL Server and refresh all data every time the user does something. There is a lot of data involved and I think that would make response time disastrously slow. In the current application, the database is accessed only when a simulation results set is created, saved, or opened, or when a customer or account is added to the simulation. The form works interactively with data in VFP cursors. I would like to keep that approach (other than the form, obviously) but don't know whether I can or not. Can the VFP side stay alive between requests from ASP.NET?

Nope you can't do that - or well you can but you shouldn't. HTTP is stateless and you can't really attach lots of state on the server and maintain it at least not with ASP.NET (or ASP) + COM.

Your only option for any kind of user state is Session state and its expensive and doesn't work well with VFP objects persisted into it (because VFP objects are STA objects that cause all sorts of thread marshalling dependencies when state is maintained).

FWIW, you could keep state like this with Web Connection because the server actually stays live between requests, but even then that's a bad idea.

You really need to think about the fact that you're building a Web application here and Web applications need to be mostly stateless from a business perspective. You can maintain state but usually you need to maintain it as part of the HTML UI (in form vars, ViewState etc.).

In addition keep in mind that using ASP.NET + COM will potentially give you some issues in passing data back and forth if you build complex types that get passed back and forth. More info here on both the mechanics and some of the sticking points:

http://www.west-wind.com/presentations/VfpDotNetInterop/aspcominterop.asp


+++ Rick ---