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