VXCMD local and remote together

[Robert Brenstein]

>on 2/18/04 6:18 PM, Ken Ray at kray at sonsothunder.com wrote:
>
>>>  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. :-)
>
>Hmm, I am not agree.
>
>And where you see easy of switch IF all your code will be explicitly writeen
>LOCAL it or REMOTE it.
>
>No guys, this is not correct.
>
>Algorithm must work with abstraction.
>For example, if you write algorithm that in loop print records of cursor
>
>     print_records( I_Cursor inCursor )
>     {
>         for loop
>     }
>
>This SIGNLE function must work with ANY I_Cursor.
>It must not care if this is remote or LOCAL cursor.
>
>This was target of all programming industry all years.
>

It seems that we look not at SWITCHING from local to client mode but 
supporting BOTH modes in parallel. For switching, yes, you are right. 
But the best that Valentina offers here is working with both modes in 
the same program.

In each mode, there are different errors to handle (it is a waste of 
time to check for connection errors in local mode, for example) and 
possibly different handling of requests (what was that discussion 
about client versus server side cursors?).

Besides, even when switching, at least in MC/Rev making a global 
rename of function call is not a big deal. And having functions that 
explicitely remind us whether they work locally or remotely makes 
more self-documenting code.

Robert