All
Accepted answers
Anthony Filaski · Oct 1, 2025 go to post

Would like to add to this. Embedded and Dynamic queries have their place. So picking one over the other really depends upon the problem you're trying to solve.
Embedded is better suited for simple queries. Use when you need to perform non-complex queries with single row result. Can additionally use embedded with cursor for multi-row results.
Dynamic, as it's properly named, is better suited for programmatically formed complex queries with many expected results. In other words, your query isn't or can't be static.
All depends on the requirements and scenario. Picking the appropriate one can help make your code cleaner and easier to read.
*Beginner Tip
One beginner mistake to look out for is ensure you understand which mode your query is using. Display Mode and Logical Mode behave differently and it is a common beginner mistake to code the query for the incorrect mode.

Anthony Filaski · May 26, 2024 go to post

Thank you for this comment, Mark. I had a similar problem which was driving me bonkers and turns out the order does matter as you pointed out. Need to do SetStream() first before setting the OutputFilename and OriginalFilename.

Anthony Filaski · Nov 8, 2017 go to post

Thanks, Marc. This sounds similar to post https://community.intersystems.com/post/how-avoid-truncation-hl7-messag…

So if I'm understanding this correctly, streams theoretically have no max size, and even with large strings enabled we would still need to look into building custom classes that access the raw untruncated stream via OutputTo* and possibly also need to use the [Get/Store]FieldStreamRaw methods for processing large messages. Correct?

Anthony Filaski · Nov 8, 2017 go to post

Thanks, Sean. I looked into our installation and long strings is enabled. So this answers my question and makes much more sense of it all. Thank you for clarifying this!

Anthony Filaski · May 15, 2017 go to post

Thanks, Jenny. I posted the solution to my problem.

 

The documentation did state certain fields could not be null, but couldn't find which specific ones it was referring to. I think it may vary depending upon which fields are being populated. All I know for sure for CareProvider is Code or Description are needed when trying to specify Name and ContactInfo. 

Anthony Filaski · May 15, 2017 go to post

Those extra dots are needed when going to HS.SDA3.Container as target in DTL. I don't know why that is but it won't work without them.

 

But found out what the issue was. I was missing other required CareProvider fields.

 

In order for any of the target.Appointments.(1).CareProvider.Name.* and target.Appointments.(1).CareProvider.ContactInfo.* fields to populate, target.Appointments.(1).CareProvider.Code and or target.Appointments.(1).CareProvider.Description must also be specified and cannot be null.
The DTL will successfully place the CareProvider info in the target message, but the ToQuickXMLStream() method will drop the CareProvider fields if both of the required fields are missing.  Which is why the message going outbound to the business operation was missing all the CareProvider fields. At least one of those fields need to be present.

 

Once CareProvider.Code or CareProvider.Description was specified, the XML Stream to the outbound TCP business operation had all the expected CareProvider SDA data.