Thanks, good to know. Sounds like the authentication is simplest way to make the thing clear.

The Id is a string of random characters, like VAzZwAod6o. And I need a way to get some more details about the session.

Thanks for the tip, but as I mentioned, so far we were not able to reproduce the problem, it comes time after time without evident reasons.

That's why I'm looking for a way to find out details of the client created the session.

As I see it, xml-to-objects classes need DOM while the whole purpose of TextReaded is to read the xml without DOM creation

Thanks, $zstorage worked fine

Thanks but  I must use xml-to-object classes generated by the xsd

Right.  Somehow I missed the evident idea that all the indexes can be simply initialized with -1 $order. Thanks. 

The only thing, last index should be not set to its previous value.

Vladimir, the question was to resume the iteration from given point. Say we have only two indexes, A and B. When resuming, the code first has to check next values of B and only then next values of A. Your code stars with A skipping all remaining values of B.

Check $query-based solution in my answer to a post below. Looks to me as more elegant than with nested loops.

>which is easy to do with $ORDER

Tried to do this but solution did not look easy at all :) 

My reworked solution so far. Looks working on samples I tested

	; Get log for given 'clientid'
	; 'maxlog' records max, starting from given 'date','dek','idx'
GetXLog(clientid,date,dek,idx,maxlog) public
{
	s:maxlog="" maxlog=400
	s counter=0
	s gl=$name(^cxlog(clientid,date,dek,idx)) ; ^cxlog("EFRW1000",20161219,2,1,"date")=20161219
	
	for { q:counter=maxlog
		s oldroot=$name(@gl,4)	; we care only about first 4 indexes
		s gl=$query(@gl)	; take next global
		s root=$name(@gl,4)
		continue:oldroot=root ; skip all sub-globals		
		
		q:clientid'=$qsubscript(root,1) ; for given 'clientid' only
			
		w root,!
		s counter=counter+1
	}
	
	w !
}

Does it work for you? I think at least the order must be c->b->a, not a->b-c

John,

• There were no changes neither to ns configuration nor to db configuration.
• Looks like ns gets its twin as soon as updated routines are imported into this namespace.
• The issue happens on production db only, we can't repeat it on test databases of same version.

If I see your explanations right, the issue is just a harmless result of some internal Cache's behaviour, so I should not really care, right? 

ok, thanks for explanations.

We do the import always in the same way for many years and never saw this problem, but I doublecheck with my colleagues the way used last time

Cache for Windows (x86-64) 2016.1

"I don't tend to use the call stack view"

I'm not able to comprehend that In my world stack view is as natural as.. as... as... I don't know, there is nothing more natural as working stack view in any debugger.

The trick with LOG^%ETN is for a case when you need the stack saved to a diagnostic log. But usual case for stack view is you have your debugger stopped on a breakpoint in some library routine and want to know what path brought you here. What you do? I look at stack view and click it to navigate to a call place.

The 'crash' is my post is actually incorrect. Studio never crashes, it always stops responding. So no error codes.

Now it took me about 15 minutes to reproduce the problem. I placed several breakpoints in my code and randomly clicked the stack every time debugger stopped, and at first everything worked OK. But then, without any evident reason, Studio stopped responding. Process info reports this:

Execution Details

Process State: EVTW

In Transaction:

No

Last Global Reference:

%apiOLE("debug")

Routine:

%Debugger.System.1

Location:

Source Location:

+415^%Debugger.System.1

Source Line:

I refreshed the page several times, the info remains the same

I don't like idea to set breakpoints in source code. At least because once set, you have to remember to remove it. This way is the only way for hardcore OS-level debugging but for application programming today I would prefer adequate debugger