Subject | How to trap a disconnection then retry the last query, etc? |
---|---|
Author | Chuck Belanger |
Post date | 2018-12-11T03:52:36Z |
Hello:
Recently, I have added the ability to connect to a shared DB on a local
network via ethernet and a shared router. Under those conditions
connection is pretty fast. I wish I had tried this sooner.
Anyway, connecting via TCP/IP is not a problem after adding an In-bound
rule to the Windows firewall. But there is an issue that can come up
that I am not clear on how to handle:
What happens if the computer acting as the DB server (can be desk top or
lap top) is accidentally turned off? This happened during one of our
tests. I have already made sure that the lap top in question is always
connected to power and that the power settings are "always on".
My question is how does one properly trap a failure to connect during
any DB activity, reconnect, then retry the last query/dsql, etc process?
My guess is that using the OnError events would help to trap the
disconnection, along with trapping for the specific error number. But,
how does one retry the last command and then continue the program
execution from where the error occurred? Can this be done or will we
need to restart the program if this happens?
Although my experience with Firebird has been primarily as a local
desktop database, it seems reasonable that the above scenario must be a
possibility that others have experienced or certainly created routines
to gracefully and transparently allow the user to continue as though
nothing happened. In this case, there would be an option to attempt to
reconnect and my hope is that once reconnected, the program can retry
and continue in the code at the point the disconnection occurred.
Thank you for any help!
Chuck Belanger
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus
Recently, I have added the ability to connect to a shared DB on a local
network via ethernet and a shared router. Under those conditions
connection is pretty fast. I wish I had tried this sooner.
Anyway, connecting via TCP/IP is not a problem after adding an In-bound
rule to the Windows firewall. But there is an issue that can come up
that I am not clear on how to handle:
What happens if the computer acting as the DB server (can be desk top or
lap top) is accidentally turned off? This happened during one of our
tests. I have already made sure that the lap top in question is always
connected to power and that the power settings are "always on".
My question is how does one properly trap a failure to connect during
any DB activity, reconnect, then retry the last query/dsql, etc process?
My guess is that using the OnError events would help to trap the
disconnection, along with trapping for the specific error number. But,
how does one retry the last command and then continue the program
execution from where the error occurred? Can this be done or will we
need to restart the program if this happens?
Although my experience with Firebird has been primarily as a local
desktop database, it seems reasonable that the above scenario must be a
possibility that others have experienced or certainly created routines
to gracefully and transparently allow the user to continue as though
nothing happened. In this case, there would be an option to attempt to
reconnect and my hope is that once reconnected, the program can retry
and continue in the code at the point the disconnection occurred.
Thank you for any help!
Chuck Belanger
---
This email has been checked for viruses by Avast antivirus software.
https://www.avast.com/antivirus