VXCMD_Client_Classic_MC

[Robert Brenstein]

>  > Ken, as far as I know, the names of resources are not wired to
>>  anything (except how they are called from Transcript), so you can
>>  rename them yourself. The only thing to figure out is how to call the
>>  right one at the right time. Of top of my head, this can be done by
>>  either duplicating the handlers for each mode or using a passthru
>>  function that knows whether you are in server or local mode and calls
>>  one or the other name.
>
>Actually, I think the problem is attaching the externals properly. If I
>attach two externals (one VXCMD and one VXCMD Client) to a Rev stack,
>they will both have the same "Valentina" entrypoint, won't they? How
>will Rev know to use the VXCMD Client when I make the call to
>Valentina("New Database", host, ...) instead of the standalone VXCMD?
>
>Ken Ray
>Sons of Thunder Software
>Email: kray at sonsothunder.com
>Web Site: http://www.sonsothunder.com/
>

Ken, the entry points into externals are normalized per API. The 
resource name is just an external binder. Try it out. Rename 
Valentina to Valentina2. Any call to valentina will fail. But if you 
change your transcripts to use valentina2, they should work fine 
again. Or so they should :)

The only thing to worry about is that each external finds the correct 
library since the externals are really just a passthru code to call 
the shared library. But Ruslan says that each external knows its 
shared library and they are distict, so there should not be a problem 
at that level.

Ruslan, having to use a different valentina call for local and server 
activities may actually be a good approach for coding.

get valentina ("SqlSelect",dbName,query)
get valentina_server ("SqlSelect",dbName,query)

This way it is easy to keep track which code works locally and which 
works remotely, particularly for programs that support both modes in 
parallel. While most Valentina functions are the same, they are not 
exactly the same and server has more of them. It is also easy to 
switch from local to remote and vice versa.

Robert Brenstein