Chad,

If you have to hold on to the VFP application, you could "wrap" it in a Windows Service. Create a .NET Windows Service application that launches one or more copies of the VFP application and keep track of the process handles. The service could then monitor the progress of the VFP application and be ready to kill the process if it is not behaving any more.

It may even be worth it to use MS Message Queue within the VFP application to communitcate with the Windows Service about the application's progress. Adding this to the VFP application shouldn't be that much work.

One final thought is to put this process on a different box that will not bring operations to a halt if something goes wrong.


>To start a total rewrite of it right now may be political suicide if nothing else.

Boy, does that sound familiar! The trick is to lead your boss to the proper conclusion in a very subtle way over the course of a few weeks. Maybe leave a printout of a whitepaper or two on his desk once in a while. Leave anonymous messages with vendors asking them to pitch your boss on their wonderful .NET tools. And my personal favorite: Add links of monster.com job postings for .NET developers to less-than-friendly co-workers' IE history folders and talk about losing developers to newer technologies at lunch.

(This is all tongue-in-cheek, of course).

>Keith,
>
>Thanks. I don't think stored procs for the processing would be efficient enough (I don't know) since I've always understood SQL to be not as strong as VFP when it comes to iterative processing. This process is VERY iterative in nature. Lots of loops within loops. A lot of the decision making characteristics of the data change as the data is being processed. Of course, I don't have any facts to back up what I've heard about SQL in that arena so I may be completely off base there.
>
>In any case, to do it in stored procs or a Windows Service (C#.NET) would mean a rewrite of the allocation engine. The engine is rather complex, flexible, and robust. It's very data driven, also. That's not to say it couldn't be (or won't be for that matter) done, but it would be a major undertaking. As it is, we've just now rolled the engine out into production. To start a total rewrite of it right now may be political suicide if nothing else. I would have loved to do this in .NET, but the project was to be done in VFP at the time. Now, we are doing future development in .NET and are already feeling the pain of situations like this where VFP may not have been the best choice.
>
>I think for now, the CLR stored proc could potentially be the way to go, but we only have SQL Server 2000 on the servers right now. All 2005 is only on development machines currently. I don't know if I can change that any time soon or not. I'll have to find out.
>
>Thanks for the suggestions.
>Chad
>
>>Chad,
>>
>>How about performing the data manipulations in SQL Server stored procedures or in a Windows Service (VB.NET or C#.NET)? That solves a lot of the problems.
>>
>>Also, I would look first to CLR stored procedures than extended stored procedures. Exended Stored procedures are on the way out.