I wondered why you mentioned dumping them to a file if they were all from a message type you didn’t need, but if it’s possible there are some errors for other message types (or other threads) mixed in, then saving them to a file would be a reasonable precaution.
If you wanted to just delete the DFT^P03 messages and leave everything else in the error db, one option would be:
hcidbdump -e -D -F -f -s 101
This would delete error messages from that thread only, and which had the specific “101” status. Then you could see if there were any errors left in the db that you cared about. I’d still advise reinitializing the error db once you have everything cleared out, for the reasons stated earlier.
If you’d prefer to save all the error messages to a file:
hcidbdump -e -b -a
This will save the messages in a length-encoded format (each message is preceded by a number giving it’s size – where it stops and the next one begins).
Whichever you choose, I’d recommend doing this from a command line. I avoid using the Database Administrator gui whenever there are a large number of messages involved, or the individual messages are very large in size. It seems like the screen can freeze up, leading to database corruption (db Vista errors). (It’s fine to use the gui screen when you are sure there are only a small number of messages.) Though you also need to be careful when using the hcidbdump command. Once you hit enter, you must just leave it alone and allow it to finish executing and return. You should never get impatient and interupt it by using Cntl-C. A handy thing about the gui is you can use it to play around with the options, and then hit the “Show Command” button (rather than “Apply”), and then copy/paste to the command line.
Now, to answer your question about resending the messages from a file. Since these are messages from the error db, that means they are the incoming message, rather than something that has gone through translation, so they would need to be re-sent to the inbound thread. Right click on the thread icon in the NetMonitor and chose Control/Full. In the Controls pop up, choose “resend”. In the “Direction” section at the top, I think you are going to want to select the radio button for “inbound post-TPS”. This is because an inbound thread is usually receiving HL7 messages over a tcp/ip connection, and is sending back HL7 Acknowledgment messages. But you are feeding in messages from a file, so there’s no need for any Acks, and I believe by using the post-TPS stack you skip over that part. Leave the Msg Type as “Data”. Use the “List” button to select the path to your file name. In the “File Format” section at the bottom be sure to change the selection to “Length Encoded”, if that’s how you saved the file. Hit the OK button, and you should see the thread get bogged down with 68,000 messages! Unless you set the priority in the resend lower than the default, real-time messages coming into that thread might get delayed until the resend is finished.
As long as I’ve blathered on this long, I thought I’d mention one other piece of advice (there’s usually several different ways to accomplish things in Cloverleaf, so compare anything I suggest with other postings on this forum). If there was a considerable gap of time between when you first became aware that you were receiving a new, unexpected message type, and when you finally got your HIS system to stop sending the DFT messages, you might have been able to reduce the impact on the error db by creating a new routing entry for the DFT^P03 messages. Do it as a raw route, with the destination set right back to the same inbound thread name, but with “hcitpsmsgkill” as the proc in the route details. That way the engine has somewhere to send the messages, even if they all get a “KILL” disposition along the way, and it doesn’t get flustered and consider them an unsupported transaction type.
In fact, something we have done a number of times is to set up a “Static” routing like this on inbound threads so that no matter what is received it has somewhere to go (and then gets killed). After that we create the individual routing entries for the message types/events we actually expect to receive and want to interface.
.
