Additional question:

When using the EnsLib.File.PassthroughService, I seem to be seeing a lot of orphan Ens.StreamContainer entries.

By all accounts, the Ens.StreamContainer entries are being sent from a service and process and does gain an entry in the Ens.MessageHeader table on creation.

When attempting to manually delete these Ens.StreamContainer entries, I do get an error:

SQLCODE: <-412>:<General stream error>]


  [%msg: <Error attempting to delete stream object for field StreamFC: ERROR #5019: Cannot delete file '\\original\path\to\file.here'>]

I'm assuming that this is due to the behaviour of the EnsLib.File.PassthroughService where it deletes the file once processed, and the delete of the Ens.StreamContainer is then attempting to remove a file that no longer exists, however the Ens.MessageHeader entry is then successfully deleted, creating the orphan.

Should this be the case?

Edit: This does not seem to be directly limited to EnsLib.File.PassthroughService as it is also present with the EnsLib.HL7.Service.FileService Service.

Thanks Jeffrey - it's certainly highlighted some hidden pockets of orphaned messages for me. I'm going to track this in a separate thread, but basically it seems there's a few edge cases where ACKs are being saved and don't end up in the IO log and don't get an entry in the Message Header table.

Based on this, is it fair to assume that the following alteration to the SQL query in Scott's above post would give a truer reflection of orphaned messages?

SELECT HL7.ID,HL7.DocType,HL7.Envelope,HL7.Identifier,HL7.MessageTypeCategory,HL7.Name,HL7.OriginalDocId,HL7.ParentId, HL7.TimeCreated
FROM EnsLib_HL7.Message HL7
LEFT JOIN Ens.MessageHeader hdr
ON HL7.Id=hdr.MessageBodyId
LEFT JOIN Ens_Util.IOLogObj ack
ON HL7.Id = ack.InObjectId
WHERE hdr.MessageBodyId IS NULL AND ack.InObjectId IS NULL