| Subject | Re: [IBO] Safe connection close |
|---|---|
| Author | Helen Borrie |
| Post date | 2003-06-10T09:16:33Z |
At 08:04 AM 10/06/2003 +0000, you wrote:
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.
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.
your DealWithIt procedure.
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
>HiNot sure what you mean by this? There are OnError events related to the
>
>If the physical connection is lost to a client, how can I close the
>db connection (tibodatabase)?
>
>The problem is there is no 'onerror'
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 connectionWhy can't you listen for these "messy errors" in the events where you know
>and you launch into a query you get messy errors.
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 connectionAgain, pick out the significant error that occurs, latch onto it and call
>also gives these erros if you try to close it.
your DealWithIt procedure.
>D5 FB1.0 IBO4.2I saw your other postings and confess that I left it alone, hoping someone
>
>I did post this request twice already with no replies. Please let me
>know if I am not providing enough info.
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