As I understand it, anywhere in code that you have an EnsLib.HL7.Message object that is created and saved, but not sent with a send request, it won't create the header and makes it an orphan. If you look through any of your custom code for anywhere you create one with a %New, or an ImportfromString or ImportfromStream, that might help track down where you are generating them from. One place you might look is if you have archiveIO turned on for anything. The messages that are generated from that tend to be orphans for me. I have a process that is similar to Daniel's for getting rid of them.
Ok got it, so your DTL is currently setting the last NTE to the OBX. To have individual OBXs for each NTE plus the original OBX you need to put in a for loop to process each one of the NTEs into a new OBX. Something along the lines of this:
I have previously used the "Resubmit at head of queue" checkbox in the Resend Messages screen to get that amount of messages sent at the front of a queue. Not great for a permanent solution, but Eduard already gave a good option for that.
That does get around having all the messages process through one iteration of changes, but it doesn't really fulfill being able to push single messages through. Thanks though!
Sorry for the delayed reply. We have gotten it working over ODBC. It wasn't a Cache/Ensemble issue, it was that the sensor in PRTG was inheriting database connection settings from the device that it was created on. Once we changed those settings it connected no problem using a windows Intersystems ODBC DSN.
go to post
Does the basic purge work for orphans? I thought that worked off the Header that the orphans don't have?
go to post
As I understand it, anywhere in code that you have an EnsLib.HL7.Message object that is created and saved, but not sent with a send request, it won't create the header and makes it an orphan. If you look through any of your custom code for anywhere you create one with a %New, or an ImportfromString or ImportfromStream, that might help track down where you are generating them from. One place you might look is if you have archiveIO turned on for anything. The messages that are generated from that tend to be orphans for me. I have a process that is similar to Daniel's for getting rid of them.
go to post
Ok got it, so your DTL is currently setting the last NTE to the OBX. To have individual OBXs for each NTE plus the original OBX you need to put in a for loop to process each one of the NTEs into a new OBX. Something along the lines of this:
Quickly tested on my system:
go to post
Hey Krzysztof,
Is the create type for the DTL new or copy? If it is copy, you probably need to also add in a remove action for the NTE(s) that you don't want.
go to post
I don't know of one in Caché, but HL7Spy is pretty good. Not free though
go to post
Hi Alan,
Thanks! That works exactly like I was thinking. Can you change your comment to an answer, or post again as an answer so I can accept it? Thanks again!
go to post
Hi Flávio,
That works with this particular global, but the method I am trying to create would ideally accept any global with any number of subscripts.
go to post
Hi Evgeny,
Thanks for the help! Those changes are committed.
go to post
Hey Jeffrey,
What is the impact of turning that setting on? Is that something that should only be done in development/test environments?
Thanks!
go to post
I have previously used the "Resubmit at head of queue" checkbox in the Resend Messages screen to get that amount of messages sent at the front of a queue. Not great for a permanent solution, but Eduard already gave a good option for that.
go to post
Birun,
Are you asking for a one time solution or a permanent solution to continuously place certain messages at the head of a queue?
go to post
Perfect! That would do exactly what I am thinking of. Thanks for the suggestion!
go to post
That does get around having all the messages process through one iteration of changes, but it doesn't really fulfill being able to push single messages through. Thanks though!
go to post
Sorry for the delayed reply. We have gotten it working over ODBC. It wasn't a Cache/Ensemble issue, it was that the sensor in PRTG was inheriting database connection settings from the device that it was created on. Once we changed those settings it connected no problem using a windows Intersystems ODBC DSN.