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

}