VXCMD_Client_Classic_MC

[Robert Brenstein]

>  > 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 :)
>
>Well, perhaps that works with Classic or Carbon, but it doesn't work
>with Mach-O. The reason is that the binding happens not as resources
>inside the resource fork of our app, but as DLLs that get linked to with
>the "externals" property.

Yes, that is surely true for Classic.

>So the "local" Valentina external is called "VXCMD_Macho_MC" and the
>"server" external is called "VXCMD_Client_Macho_MC". Both of them get
>calls through the function name "Valentina". So if I link both externals
>to the same MC stack, when I call on Valentina(...), which external gets
>used? In my experience, MC will pick one over the other (I think it goes
>by alphabetical order), but regardless, I can't link both externals into
>the same stack.

I claim ignorance here as I haven't worked with Macho yet. I presumed 
that the external property binds only the file. No clue how 
"valentina" name as function comes into play here.

>So in my app right now, I have two separate stacks, each one linked to
>its own external, and then a login dialog in our product determines
>whether the user wants to access a local DB or a server-based DB. And
>*then* I connect to the proper stack and are able to use the right
>external. But it's a bit of a pain...
>
>>  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.
>
>I totally agree. :-)
>
>Ken Ray

Looks like Ruslan sees it other way :)

Robert