Hi Alexander.

Sorry for being pedantic, but you're missing the ending quotation mark when setting the value of 'sql'

SET variable = 2000
SET sql = "SELECT Column FROM Table WHERE ID = ?"
DO ##class(%SQL.Statement).%ExecDirect(, sql, variable)

Yes, I believe so.

The general principle is that the message is evaluated to see if it is eligible for being sent before the transform begins.

Hey Enrico.

The value of KeepIntegrity is set to True. I don't believe we have ever run the purge without including message bodies, but it's a non-production environment so stranger things have happened.

However, I did also just try running ##class(EnsLib.HL7.Message).Purge() in our production environment with the settings matching the retention period there, and it ran for a period, freed up around 5gb and then failed over to the other mirror as running the method consumed all of the ram on the box 😅
This namespace has been around for a long time (started life at around caché/ensemble 2014) and has likely accumulated a lot of baggage. I had a similar problem when trying to run Ensemble Orphaned Messages Purge Routine 

Hey David.

Your solution has caught my attention. What led you to this?

I have just run this against a non-production namespace that had a 30 day retention period and was sat at around 6GB. Running this command with the "pDaysToKeep" parameter set to 30 days has managed to free up 5GB and deleted 92158 messages, where I would have expected to have not deleted anything given the retention period for the purge task and the running of this method were the same.

Please look here for the solution: https://community.intersystems.com/post/base-64-message-taking-consider…

So to do what you're trying to do in your DTL, add in a code block and paste in the following:

  Set CHUNKSIZE = 2097144
  Set outputStream=##class(%Stream.TmpCharacter).%New()
  Do source.EncodedPdf.Rewind()
  While ('source.EncodedPdf.AtEnd) {
    Set tReadLen=CHUNKSIZE
    Set tChunk=source.EncodedPdf.Read(.tReadLen)
    Do outputStream.Write($SYSTEM.Encryption.Base64Encode(tChunk,1))
  }
  Do outputStream.Rewind()
  Set Status = target.StoreFieldStreamRaw(outputStream,"OBXgrp(1).OBX:5.5")
  )

Yours is almost doing the same thing but, as Enrico points out with your code sample, you have the "Set tSC = tStream.Write($C(10))" line adding in the line breaks whereas my example has this excluded.

Separately, as alluded to by Scott, when adding the base 64 encoded PDF stream to the HL7, you'll want to use the StoreFieldStreamRaw method for the HL7. Trying to do a traditional set with a .Read() risks the input being truncated.

Ahh, I see what you mean.

I have not had to work in this way with IRIS and OpenEHR, so unfortunately I wouldn't be able to provide much insight.

The link in my last reply actually contains the answer, which is always useful. I have tweaked it slightly so that it's a single line, but the output is the same.

To get the current date and time with milliseconds, you can do the following:

WRITE $ZDATETIME($ZDATETIMEH($ZTIMESTAMP,-3),3,1,3)

This is:

1. Starting with the output of $ZTIMESTAMP
2. Converting to a $HOROLOG format adjusted for your local timezone using $ZDATETIMEH
3. Converting to the desired format using $ZDATETIME

I hope this helps!

This will be that caveat I warned of which is detailed in the documentation.

You could do something like:

Write $ZDATETIME($h_"."_$P($NOW(),".",2),3,1,3)

Which takes the value of $H and appends the milliseconds from $NOW() to then form your datestamp:

However the documentation I linked to warns that there can be a discrepancy between $H and $NOW() so this approach could then lead to your timestamp being off by up to a second. As you are trying to work to the level of milliseconds, I suspect accuracy is very important and therefore I would not recommend this approach.

Take a look here and see if this example of comparing $h, $ZTIMESTAMP, and $NOW() helps, and the example of converting from UTC to the local timezone helps.

Although I have seen environments where namespaces are used to separate Dev/Test/Prod etc. I have found that having the Prod environment on the same environment as the Non-Prod Namespaces is a risk to the Prod environment should an active piece of development take down the underlying machine (one example was a developer* making a mistake when working with Streams and had created an infinite loop in writing a stream and the server very quickly gained a 10GB pdf that filled the disk to capacity and the environment stopped working).

A common use case for multiple namespace for me would be for instances where the activity within the namespace is significantly distinct from the others. For example, we have a namespace that is dedicated to DICOM activity. While we could have put this in a single "LIVE" themed namespace, the volume of activity we'd see for DICOM would have filled our servers disk if kept to the same retention period as other standard retention period. So we have a DICOM namespace that has a retention period of around 14 days compared to others that are between 30 and 120 days.

*It was me. I was that developer.