I am still 'stuck' with the problem of trying to reconnect the
tibodatabase when the physical connection is reconnected. If you
break the physical connection the VerifyConnected returns false. If
you reconnect the physical connection the VerifyConnection still
returns false, and the ibodatabase still reports 'Connection Lost'.

I find temporary network losses common around here (South Africans
buy second hand network cables from India) so this issue is fairly
important to sort out.

Thanks

Rod

--- In IBObjects@yahoogroups.com, Helen Borrie <helebor@t...> wrote:
> At 08:04 AM 10/06/2003 +0000, you wrote:
> >Hi
> >
> >If the physical connection is lost to a client, how can I close the
> >db connection (tibodatabase)?
> >
> >The problem is there is no 'onerror'
>
> Not sure what you mean by this? There are OnError events related
to the
> API, which will trap errors from the server through the API
> structures. This will be ever-so-slightly-problemmatical if you
pull out
> the network cable - so you've got to trap the client-side errors
that will
> occur when an object tries to do something that it needs a live
connection
> for.
>
> >and if there is no connection
> >and you launch into a query you get messy errors.
>
> Why can't you listen for these "messy errors" in the events where
you know
> they occur? Latch on to any that occur when the network connection
is lost
> and, for example, protect the Open and Post events of datasets with
> try..except blocks and raise a custom exception to trap these
particular
> errors.
>
> Then you can handle them by calling a DealWithIt procedure that
> 1. verifies that the connection is lost
> (TIBODatabase.VerifyConnection). If it returns True (= still
connected)
> then Exit and hand it on. Otherwise, it's False, so your procedure
then
> 2. cycles through the open datasets, aborts any pending DML
operations and
> closes them.
> 3. cycles through the transactions and closes them.
> 4. sets the connection's Connected property false.
>
> >The db connection
> >also gives these erros if you try to close it.
>
> Again, pick out the significant error that occurs, latch onto it
and call
> your DealWithIt procedure.
>
>
> >D5 FB1.0 IBO4.2
> >
> >I did post this request twice already with no replies. Please let
me
> >know if I am not providing enough info.
>
> I saw your other postings and confess that I left it alone, hoping
someone
> expert with this problem might pick it up for you. I'm seriously
(and so
> far unsuccessfully!) trying to avoid getting caught up in anyone's
support
> scenario this week, as I have an important deadline on Sunday for
the
> Firebird book, and it won't wait.
>
> I can't promise you that my suggestions will give you the perfect
solution,
> but it might at least get you onto your own track for solving it -
or
> prompt Jason to say it's a load of @%$#$!%$ and steer you where you
need to
> go. :-))
>
> cheers,
> Helen