Dear Mike:

Thanks for the really great info.
What parameters would you recommend for SYS3050?

Thanks
Bruce Strom


>>My concern in rewriting my FoxPro application as a DCOM object is the fear >that I will spend tons of time learning and writing it
>
>Check out Chapter 16 in the Programmer's Guide. I don't remember anyone who followed the "Using Remote Automation" section to the letter who couldn't get it working. Not much of a learning curve, IMO.
>
>> and run into some funky >API or DLL error message when it is done that I just
>>have tremendous >difficulty resolving.
>
>Debug it as a regular app first, then turn it into a COM server. Since you won't have any UI, debugging it as a COM server will be difficult, so best you run it as something you can check in the debugger first.
>
>>The question is: is it safe to write DCOM objects in VFP, or is the VB >environment a safer platform?
>
>No, VB is not the "safer" platform. Plenty of folks are using VFP DCOM servers just fine.
>
>>First, VB appears to be the favored deveopment environment.
>
>Favored by whom? I don't favor it, in fact I barely touch it. If VFP can't do the job, then I'll fire up the VC++ compiler. VB rarely enters the picture for me. Obviously, some folks differ with my opinion. Use the tool that works best for the job, not what's most popular.
>
>>Second, I have heard that Foxpro uses non-traditional aggressive memory
>>management techniques.
>
>Easily remedied with Sys(3050) and MEMLIMIT in the CONFIG.FPW. See:
>http://support.microsoft.com/support/kb/articles/Q129/3/11.asp?LN=EN-US&SD=gn&FR=0
>http://support.microsoft.com/support/kb/articles/Q130/5/22.asp?LN=EN-US&SD=gn&FR=0
>http://support.microsoft.com/support/kb/articles/Q136/6/94.asp?LN=EN-US&SD=gn&FR=0