[Anthony Kirk]

To start you need to ensure there are no other users accessing your site.  Stop any remaining processes that are running – attempt to do so in an order that flushes any messages through first.  Wait for that to complete.  If there are any messages in the error and recovery databases you haven’t handled yet and can still access, bearing in mind your error message suggests the error database itself is corrupt, dump what you can to a file/files.

Then through a shell window (open from the runtime menu if you need) paste the commands in the attached CleanUp.txt file – extracted from an old iSoft clean-up script.  This begins by stopping the Monitor Daemon, deletes the shared memory from the exec folder, removes the region from the statistics interface (the “-Z” switch zeros the statistics too but that’s personal preference), then rebuilds the error and recovery databases.  It’ll warn you “this is an extremely destructive operation – do you wish to continue?”  It’s Hobson’s choice really!  You’ll get an error if the files are in use (remember I mentioned you need to kick off anyone else earlier) and the operation will fail. Otherwise you’ll be good to go and can start the monitor daemon and bring the interfaces back up.  Don’t forget to send those messages you salvaged from the recovery database first, if you had any.

We normally run through this whenever there’s a “panic”, so error messages may still be salvageable in that state.

Attachments:

You must be logged in to view attached files.

[Anthony Kirk]

It is true that performance improves when you open the database at startup and close it at shutdown.  A database can be closed, reopened and your action upon it repeated upon an error (so long as you catch it).  For my SQL server connection I add a 5-second sleep into the process – we could all do with a power nap sometimes!  You can repeat that x number of times until you give up.  At that point you should be deciding whether it is safe to continue the message you have without the additional data, or change the disposition like Charlie said.

 

This is just a hunch but are you capturing the dates of birth of all neonates ad infinitum?  Your database will be significantly smaller if you remove entries beyond day 28.

[Anthony Kirk]

Sending the message in several parts was part of our original approach. Each data message generated a “header” segment, continued as a message, then the data (segment 2) was continued as another message.

The problem we had was several messages attempting to be sent simultaneously. Data1 and Data2 would arrive on the outbound thread. Data1 generated Header1, Data2 generated Header2. The receiving system would receive Header2 before Data1, assume the content of Header2 was actually Data1, get in a tizz and stop handling our messages (oh the joys of CLINiCOM !)

I think our next step would be to add the header into all our xlates, unless anyone has a better solution…

[Author]

Replies