>Ed,
>
>That's impressive that even COM servers can withstand that many instantiations without crashing. Maybe this VFP thing ain's such a bad tool after all. *LOL*

The COM Servers themselves aren't written in VFP; we're stateful, requiring us to maintain context between calls by multiple clients when run out-of-process, and there are some sections of code that need fast, reliable IPC and mutex. Plus, some of our deployment targets are going to require that they run free-threaded, and VFP can't do this. The object being instantiated is moderately complex, with several collections and lots of variants, so ample opportunity is being given to lose a few bytes here and there in the course of interacting with VFP's OLE stuff. To give you an idea of what we're doing:

set talk off
set safety off
LOCAL oDeliveryCommit, oDeliveryCommitInputs, oDeliveryCommitResults, nTokenRows, nEachToken
*  Get the token set for the test cases
SELECT * FROM TokenSrc INTO ARRAY aTokenList WHERE ! DELETED()
#DEFINE CARTOKENCOL 1
#DEFINE SVCTOKENCOL 2
nTokenRows = _TALLY
nStartOrig = 0
*  Save the result set
CREATE TABLE DCResults (CarToken I, SvcToken I, Orig I, Dest I, NumDays I, DateDeliv C(8), ErrCode I, TransDur N(8,4))
activate screen
LOCAL nOrig, nDest, cOrig, cDest, nErrCode, cDateToShip, cDateToRcv, tStartInvocation
cDateToShip = DTOS(DATE())
cDateToRcv = DTOS(DATE()+10)
lSetExit = .F.
*  Do a million GetDeliveryInfos()
FOR nOrig = nStartOrig TO 999
	cOrig =PADL(nOrig,3,'0')+'01'
	wait window 'Origin ' + cOrig nowait
	oDeliveryCommit = createobj('CMU.DeliveryInfo')
	oDeliveryCommitInputs = oDeliveryCommit.DeliveryInfoInputs
	oDeliveryCommitResults = oDeliveryCommit.DeliveryInfoResults
	FOR nDest = 0 TO 999
		tStartInvocation = DATETIME()
		cDest = PADL(nDest,3,'0') + '01'
		oDeliveryCommitInputs.RemoveAll()
		oDeliveryCommitResults.RemoveAll()
		WITH oDeliveryCommitInputs
			.OutputOrder = 0
			.DateFilter = ""
			.TimeFilter = ""
			FOR nEachToken = 1 TO  nTokenRows
		
				.add(aTokenList[nEachToken,CARTOKENCOL], ;
					 aTokenList[nEachToken,SVCTOKENCOL],'','')
			ENDFOR
		ENDWITH
		WITH oDeliveryCommit
			.OriginZip = cOrig
			.DestinationZip = cDest
			.ShipmentDate = cDateToShip
			.TargetDeliveryDate= cDateToRcv
			.TargetDeliveryTime = "1600"
			.GetDeliveryInfo()
		ENDWITH
		FOR EACH Result IN oDeliveryCommitResults
			INSERT INTO UPSGRResults VALUES (	Result.CarrierToken, ;
												Result.ServiceToken, ;
												nOrig, ;
												nDest, ;
												Result.DeliveryDays, ;
												Result.DeliveryDate, ;
												Result.ErrorCode, ;
												DATETIME() - tStartInvocation)
			IF Result.ErrorCode = 0
				lSetExit = lSetExit OR ! BETWEEN(Result.DeliveryDays,1,20)
			ENDIF
		ENDFOR
		IF lSetExit
			SUSPEND
		ENDIF
		IF inkey() = 27
			EXIT
		ENDIF
	ENDFOR
	*  Delete object refs when done
	oDeliveryCommitResults = NULL
	oDeliveryCommitInputs = NULL
	oDeliveryCommit = NULL
	FLUSH
	IF INKEY()=27
		EXIT
	ENDIF
ENDFOR
CLOSE DATA

>
>I've had two separate VFP COM servers running continuously on a data acquisition system since 6/10/98 and the system only has been down twice since then to install new versions as we've brought new features online.
>
>>Dave, I've done something like this already in the course of testing the integration of one of our COM Servers with a VFP application; we ran over 67,000,000 consecutive CREATEOBJ() instantiations of our in-proc server without having VFP complain about memory loss. We did grow the swap file a bit (not surprising, since we use mapped file I/O for inter-instance communication) but VFP never complained about a lack of memory internally. We even tried multiple sessions of the test app running on the machine, each repeatedly creating and releasing the in-process server. VFP wasn't bleeding.