Hi Trey

Vfp7t.dll is not to blame: You 've hit a limit placed into COM+ thread pool to prevent excesive resource consumption: only 8 "STA threaded" objects active at the same time in a single-processor machine (BTW, you get 1 object more for each additional processor). Both VFP and VB COM objects suffer the same limit, it's something about the threading model and not the language used.

You can find detailed information in: http://support.microsoft.com/default.aspx?scid=kb;en-us;Q282490

Though there are certain ways to workaround that limit, the suggested solution is to avoid as much as possible blocking a COM method for a long time.

So you should see why are your methods taking too long: if there is just a "Sleep" API call -placed for testing purposes- remove it, its not a wise test. If it is the SQL data access which takes a long time, you should use asyncronous access -I can give you more details if needed-.

Regards,
Jose.

>We have an intranet database application with business logic in VFP7 under COM+ on Win2k Advanced Servers. (not using any .NET)
>When QA is testing, they will be frozen with only around 7 or 8 screens active. A dump of file locking shows that the vfp7t.dll is (or seems to be) the culprit, with the same number of locks as screens active (naturally).
>Across instances of freezing, there doesn't seem to be a common COM server involved.
>
>Any ideas?
>I've kept this question general at first to get a wider variety of narrowing down questions.
>TIA