That is correct, however it is far simpler if you use the debugger built into VS Code as this uses our maps from class to INT code to automatically set the correct breakpoint based on the source class line.

If you have logic that is making an assumption about what label name we use for a specific method then this logic will need to be updated.

We ship the XSD file as part of the IRIS installation. You can find it under <install dir>/bin/irisexport.xsd. It varies from version to version as new keywords are added, but we use this to validate any XML before importing an XML export.

Cached queries are kept until they are explicitly purged or you upgrade your IRIS instance. So it is only useful to run this after an upgrade of IRIS or after you explicitly purged your cached queries.

In 2020.2 we added $system.OBJ.GenerateEmbedded function which allows all universal cached queries to be compiled on a customer system even if all the routines/classes are deployed. So this function can be run after installation to prepare the SQL queries before you bring the system up.

You are doing disk block reads in the one case which is why it is slower, how big is your global buffer pool? Also how big are your globals ^TestD and ^TEST2, use 'd ^%GSIZE' to find their sizes on disk. The $lb version will be slightly bigger as there is a byte taken as a type byte for each element and another length byte, this shows up when the data is very small like these single character ASCII elements, but $lb does mean you never need to worry about data that contains '#' characters and it preserves types where as the "a#b#..." format needs to convert everything into a string before storing it which adds runtime overhead too.



The behavior you are seeing is because of chain '.' handling of null objects. For example if you:

Set person=##class(Sample.Person).%New()

Write person.Name.AnythingYouLike

It will succeed and return "", but if you:

Set tmp=person.Name

Write tmp.AnythingYouLike

It will fail with an INVALID OREF error, as would 'Write (person.Name).AnythingYouLike'.

This behavior is inconsistent, so I will not defend it, but it is how the product works.

Hi John,

Unfortunately the generated code is only held long enough to build the class routines and then is discarded. The problem is this takes up a lot of space and we want to keep the size of ^oddCOM down to something fairly reasonable so there is no official way to obtain this.

Either will work, but referencing the 'Name' property is a lot faster.

A few comments:

  • %ResultSet does have %Execute, %Next, %GetData, %Get, %Prepare methods also
  • In %ResultSet use 'Data' multidimentional property to get columns by name as this is more efficient than the 'Get' method.
  • In %SQL.StatementResult, do not use %Get to get columns by name, instead just reference the properties directly, e.g. 'Write resultOref.Name' instead of 'Write resultOref.%Get("Name")'