>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