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
}
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?
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.
It's also possible to override the adapters and get the data from your own data within the namespace.
Override the AssignOneSetting method in the adapter your operation is using to get the setting value from somehere of your choosing.
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
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
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
What are the advantages of doing this over using a fhir server?