Regarding 

• <Invoke> in module.xml behaves more intuitively by always checking the %Status return value if and only if the method signature declares %Status is returned. This means an error will be thrown if nothing is returned, the return value is not a %Status, or it is not $$$OK.

If we have 

specifically

        <Invoke Class="RCIPM.Utils" Method="MakeModuleDeployed" Phase="Compile" When="After" CheckStatus="false">

            <Arg>{$root}</Arg>

            <Arg>{$verbose}</Arg>

        </Invoke>

CheckStatus="false", is it still going to check the status.  sorry if I'm reading this incorrectly.

I guess then reading further I see

• #828: The CheckStatus flag for <Invoke> action has been deprecated. Default behavior is now to always check the status of the method if and only if the method signature returns %Library.Status

so it would appear, yes, the CheckStatus attribute is now going to be ignored.

I have 109 examples across 31 modules that use CheckStatus="false"

some of these are during the Phase="Clean" where I dont care if the Invoke succeeds completely or not during a Clean.  

With the behavior of modules being all part of a TSTART if any of the Invokes return an error %Status then the module is not installed and everything is TROLLBACK'd. in the case of Invoke I dont have a super string feeling about some of the <Invoke>s, if they fail I still want the module installed.

Ben,

  Can you provide some clarity around why some of your SQL statements which are SELECT statements do not use 

%NOLOCK

while one of them does use %NOLOCK.

I always thought a by default a SELECT statement does not attempt to lock any of the records of any type of lock.

If I study the ObjectScript code generated to satisfy a SELECT statement like

select id from ens.messageHeader

it's not clear that any of this does any form of a lock(whether exclusive, shared etc)

%0Afirst 
 ; asl MOD# 2
 set i%Vsb23=""
%0AmBk1 s i%Vsb23=$o(^Ens.MessageHeaderI("Extent",i%Vsb23),1,i%Vch24) i i%Vsb23="" { g %0AmBdun }
 s i%Vhi25=i%Vsb23-1*64000
 s i%Vvecvar17=$vop("+",$vop("positions",i%Vch24),i%Vhi25-1)
 ; asl MOD# 3
 set i%Vlo26=""
%0AmCk1 s i%Vlo26=$bitfind(i%Vch24,1,i%Vlo26+1) i 'i%Vlo26 g %0AmCdun
 s i%IDO1=i%Vhi25+i%Vlo26-1
 s i%IDO1=$ve(i%Vvecvar17,i%Vlo26)
 s:$g(SQLCODE)'<0 SQLCODE=0 s %ROWCOUNT=$i(i%rowcnt),%ROWID=i%IDO1,i%CursorState=10
 //-- FETCH Output
 set:$l($g(i%querystats)) i%time=$g(i%time)+$zh-$lg(i%querystats),i%commands=$g(i%commands)+$zu(61,8,$zu(61))-$lg(i%querystats,2),i%querystats=""
 quit
%QRS0f //-- FETCH tag
 i '$g(i%CursorState) { s SQLCODE=-102 q  } i i%CursorState=100 { s SQLCODE=100 q  } s SQLCODE=0
 i i%rowlimit,i%rowcnt'<i%rowlimit { s SQLCODE=100,%ROWCOUNT=i%rowcnt,i%CursorState=100 q }
 Do $system.Process.AppFrameInfo(i%StackInfo) 
 set i%querystats=$lb($zh,$zu(61,8,$zu(61)))
 g %0Afirst:i%CursorState=1
 g %0AmCk1
%0AmCdun g %0AmBk1
%0AmBdun 
%0AmAdun 
 s %ROWCOUNT=i%rowcnt,SQLCODE=100,i%CursorState=100
 set:$l($g(i%querystats)) i%time=$g(i%time)+$zh-$lg(i%querystats),i%commands=$g(i%commands)+$zu(61,8,$zu(61))-$lg(i%querystats,2),i%querystats=""
 //-- no [more] data
 quit

While the above is for a simple query and is completely index satisfiable, i.e. it doesnt have to read from the mastermap I dont think the question of lock/nolock changes for a SELECT statement.

Question:

Why would the usage of %NOLOCK ever come into play?

you can quickly access the SQL shell witj

USER>:SQL
SQL Command Line Shell
----------------------------------------------------
 
The command prefix is currently set to: <<nothing>>.
Enter <command>, 'q' to quit, '?' for help.