True. And it depends on how logically the globals were set up in the first place as to whether the mapped tables/classes can reflect a sensible logical schema. You could still map them without that but it wouldn't be great for usability.
They can exist without SQL access but you can always make them available through SQL at a later date by mapping a class to them.
If you're using IRIS to transform other message formats to and from FHIR using DTLs/Apis or some other way then you'll need to implement the profiles yourself. You can create your own DTLs based on the ones in IRIS to implement the profile constraints and extensions or you can code it yourself.
What are the advantages of doing this over using a fhir server?
Look at the parameters you can pass to the use command - the below will do what you want
u $i:(:"+S")
read password
or if doing directly at the command line instead of from a called routine
u $i:(:"+S") read password
Check whether the tstart command is issued with a post conditional parameter if so then you may be able to make the ts fail and therefore the ts would not start the transaction.
For instace if you had:
Tstart:$g(^startts)=1
Then killing ^startts would cause the transaction not to be created.
#longshot
Have you tried looking at the query plan for your query to see which indexes it is using and whether these appear to make sense?
It appears that the generated query will often ignore the sessionId index as below:
%IGNOREINDEX Ens.MessageHeader.SessionId
Override the AssignOneSetting method in the adapter your operation is using to get the setting value from somehere of your choosing.
It's also possible to override the adapters and get the data from your own data within the namespace.
It was more about whether the generated INT code would still be marked as run by the monitor and whether I could still link the run code back to the class method.
Is this change going to affect the results of calling %Monitor.System.LineByLine and liking the generated INT code to the class code by using $text in order determine code coverage when running unit tests?
Also look at the %SQL way of running queries which has some advantages, there are a few ways of doing it, one of which is:
s stmnt=##class(%SQL.Statement).%New()
s sc=stmnt.%PrepareClassQuery("GMECC.DocmanConnect.Tables.vwNewGPs","GetRows")
s rs=stmnt.%Execute()
w rs.%SQLCODE,!
while rs.%Next() {
// s var=rs.%Get("ColumnName") - for known column names
s var1=rs.%GetData(columnNumber)
w var,!
w var1
}