4gl error management - handling database going down

[WiccaChic]

Hi all. My show has never really put much work into monitoring for and managing errors in their 4gl apps and I have been told that something is impossible to do and I want to get some "less invested" opinions. If we have 4gl (4ges) running on our server that are connected to the database, and the database hits an assert failure and goes down, the 4ges totally poop their pants and die. Is their a way to monitor for this kind of failure in the 4gl and maybe go into a recovery mode and just keep trying to reconnect to the database until it comes back up? The programmers here treat me like a leper for even asking.
-thanks

 

[olded]

Hi:

Shutting down the database on an executing 4GL program is akin to shutting off the lights and running around in the dark. Sooner or later, you'll trip.

You can't stop the 4GL from "pooping its pants" (great analogy), but you can make an effort to trap for errors when executing a data management statement, DML, and failing gracefully if there is a problem.

This means if opening a database, checking if opened; checking the return status (usually sqlca.sqlcode) of each select, insert, delete, and update statement. This also means checking the status when building cursors - something most programmers don't do. This means checking each PREPARE and DECLARE statement to make sure it executed correctly, and failing if it didn't.

What's the obvious downside? This means a lot more coding where you may not have been coding before.

Not every assert failure results in the database going down. But it's my opinion and experience, that an assert failure that does take the engine down is probably going to do a number on your executing 4GL programs. Whether the added coding I've discused would help trap an assert, is problematic.

Regards,

Ed