>
>Which is NOT multi-use. Perhaps a better term is multi-threaded, it's not.
>

You've got to be very careful here. VB objects are not multi-threaded, yet they can run multiple instances at the same time. This is a trick really - each
object gets its own copy of the runtime so it simulates a multi-threaded
environment, but it isn't multithreaded. Multi-threaded implies re-entrant
code - IOW the same physical block of code can run simultaneously. C/C++
allows you to write real multi-threaded code. Ironically, COM does not
work all that well with true 'Free Threaded' objects - preferably objects
should conform to Single Threaded Apartment model threading. VFP6 actually
does conform to this model, but has internal blocking to prevent simultaneous
operation of method/property access.

VB and VFP only simulate this by loading mulitple areas in memory with
the same code and their own private Thread Local Storage.

The problem with VFP is that there are a lot of globals, which apparently
can't be isolated easily and stuffed into local storage for each object.
From what I can see the blocking is required to protect those globals from
getting hosed by simultaneously running instances. Globals being things related
to the database engine and the environment like SET commands, data bufffers
etc.

+++ Rick ---