did you try to Save your Stream.Container ?

set tSC = tRequest.%Save()

before 

set tSC = ..SendRequestAsync(..TargetConfigNames,tRequest)

my personal rule:

• In the development stage, programmers should have full access but data are anonymized.
• In the test stage - only some qualified developers get limited access
• in the production stage, neither users nor developers should have access to the studio or terminal.
  Access is given only temporary, to top experts for error analysis.
  That's like the doctors that take care of places of your body you won't' show to anybody else.
   

Yeah!
you can lock out developers from SMP.

But you can't prevent them from writing code with similar functionality. And run it.
And then you have the same SYSTEM privileges as your Caché installation has. 

It might be hard to block it.

For stronger security block all developers on production systems. 

I like the second solution!   
really excellent  ​​​​​​

not at all. It's just a readable formatted picture of the executed code.

Ah, got it.
I understand and agree on 7, 8, 9

for 1. I still wait for the "modern" editor. 
None of the existing ones could really convince me. But all are easier to handle than vi or X ^%  

Yes.

it prevents an error message if there is a collision.
if nobody else is around it just falls through without loop.

misunderstanding:

I suggested to just use that EXAMPLE method to write a HTML structured table.
Variation is in the SQL statement that you pass to it 

ClassMethod any(sqlStatement as %string) As %Status  {  
     set query = ##class(%ResultSet).%New()   ,
     sc = query.Prepare(sqlStatement)
......

}

In docs you find Persistent Objects and Caché SQL

especially storage definitions

For more information on the globals used for persistent classes, see “Globals.”

Assuming you get the call string as the variable parameter then

for par="SERVER","PORT","NAMESPACE" set @par=$P($P(parameter,par_"=",2),":") zw @par
SERVER="127.0.0.1"
PORT=1972
NAMESPACE="SAMPLES"

you can delete the class in Studio or from SMPortal.
so you delete the class DEFINITION and the related table DEFINITION. but no  data.

BUT.

DROP TABLE in SQL also deletes the data  AND the definition because this is part of SQL Standard. (Se also MySQL)

I'd suggest you take some time to really read the documentation or consume some online training.
 

" In MySQL, a "view" is just a saved SQL query - dropping a view does not drop data. 
I never imagined dropping the class  (which I thought was just a view) would empty the global. 
The global was still there, but all the data was gone. "

Caché is different from MySQL but has also VIEWS and dropping a View doesn't touch any Data

But identical as in MySQL DROP TABLE deletes the data.

from http://www.mysqltutorial.org/mysql-drop-table
The DROP TABLE statement removes a table and its data permanently from the database. 

and this was your question:
So how else do I drop the table?

and later:
 I did one by DDL 

if you use DROP without option %NODELDATA  your data are gone. 
https://docs.intersystems.com/latest/csp/docbook/DocBook.UI.Page.cls?KEY=RSQL_droptable

Short Caché Basics:

• all data are stored in globals, nowhere else
• classes describe the structure how data are stored and can be accessed as Objects or Tables. 
• classes never change, generate or delete data, but provide methods to do so.

so having 3 'tables' on the same global is just having 3 views of the same house.

Recommend readings: Long Caché Basics and Introduction to Caché SQL

OK. I experienced that scenario quite often. 

Suggestion to verify that indices will help you.
- Take a typical class definition, make a copy without storage definition (or remove it)
- compile it with Chaché Default storage and  run  INSERT INTO new.table SELECT * from old.table a flat table scan
- verify the new table against your needs. 
- if it fits then the problem has moved to "update frequency" which might be easier to solve.
It's, of course, limited to the critical tables and not the whole DB

You shouldn't be so much concerned on looping the RecordSet
INSERT ...... SELECT ....  
looks smaller and smarter  but does basically the same

Well the code you posted shows a rather ancient type of table mapping away from standards.

And the errors you got underlines this as standard methods like %BuildIndices and %PurgeiIndices are not implemented.

I see 3 possible options:
- you find in the code (not necessarily in the class definition) some method to (re) generate the indices. 
Without experience with Caché and Object Script a rather impossible task.

- you create a copy of the class definition and move all data there by INSERT INTO new.table SELECT * from old.table
but it is unclear from what you showed to us if INSERT into your table is supported at all 

- least risky. you out-comment all broken indices except [IDKEY] and just use a flat table scan.
this is a fast workaround at the price of a poor performance on bigger tables.

honestly. - not a funny situation