>>>>>Walter, fairly sure it's caused by the code downloaded from the wiki that uses an object property to store the message byte by byte. As you'd expect, I'd have used a VFP cursor with a memo field that runs like a scalded cat even if it decides to spool to disk... but see other message for the solution I think we came up with.
>>>>
>>>>John, just stumbled across this message. Were you able to resolve it?
>>>>We have stumbled with similar problems, only to find out that the WinSock control needs to have the ERROR event implemented. If you don't your application will freeze and eventually run out of memory.
>>>>
>>>>also, just use TRY CATCH to catch any error and log it.
>>>
>>>even with try catch in place there is a good chance that your memory will be leaking/fragmenting without GC able to compact free areas due to error [objects?]
>>
>>Not sure what you mean. GC? FWIW, we've got HL7 interfaces that run for years without interruption, pure VFP code.
>>
>Garbage Collection.
>Some errors will make piecemeal out of vfp memory, even if the offending line is encapsulated inside try-catch blocks if encountered often enough.
>So even if John puts Try-Catch arount the line, chances are that after logging a few hundred errors the application still could either run out of memory or slow down so much to be unusable.

Hmmm, I've never experienced that, even with tens-of-thousands of catched errors. Anyways, its important that the errors are logged so you can do something to prevent them.