[V4RB][VSRV] - Status of Connection

[Russ Tyndall]

On 4/22/06 12:56 PM, "Ruslan Zasukhin" <sunshine at public.kherson.ua> wrote:

> On 4/22/06 4:08 PM, "Russ Tyndall" <fitzbew at nc.rr.com> wrote:
 
>> There is some discussion about this in the archives, but it left me a bit
>> puzzled.
>> 
>> What is the best way to verify a Vserver Client connection is still alive
>> (has not timed out, etc..)?  Db.IsOpen?
> 
> If I not mistake Vserver.Available property exists.
> 
>> Also saw a suggestion that the client should just try to perform whatever
>> action it wishes (like build a recordset) and then just cope with any
>> errors.  Are there reliable error codes?
> 
> Yes, please check Vcomponents/Resources/.xml files for error codes.
> 

I think I am approaching this problem in a too simplistic way.

Suppose my app launches and connects to vserver and all is well and good.

Then, a lazy employee (read: me) goes on a coffee break and vserver drops
connection after twenty minutes.

Employee returns and starts to use app and interact with vserver. Naturally,
exceptions occur, unless app is programmed to cope.

Before each server-involved action, should I test for valid connection, and
try the server-involved action if connection is valid?

Or, should I use a "Try..Catch" blocks and test for vException" and then try
to reconnect and continue the operation that threw the vException?  If I go
this second route, how can I tell that it was a connection time out? If I am
trying to build a cursor, it could throw an exception for a lot of different
reasons, right?  I would only want to attempt a reconnect under some
circumstances, I think.  Is there a way to get any visibility into the
nature of the vException in RB code? (I see that db.ErrNumber is deprecated
in 2.x so I guess I should try and avoid using db.ErrNumber in a new app?)
I know that the error codes are logged depending on verbose level, but that
doesn't help here.

I guess that sometimes it's just impossible for a client to know why a
connection was dropped.  In this case, it seems to me to be more logical to
verify a valid connection *before* server-involved activity and try to
reconnect at least once if no good connection is found.  A connection could
die and it might have nothing to do with timeout.

The best solution for this kind've problem might vary between different apps
and different network environments.

Russ