Michael,

Thanks for this tip.  I'm using this utility to programatically export part of a very large global to a file, for archiving data.  I've decided that using the %Global.Export() method is the best way to go, since I have to do this in code without user input from a terminal. I considered ^%GOGEN and $system.OBJ.ExportToStream as well (comments on this?)

Previously I was merging the global part to a temp global in another namespace (the namespace would then be deleted), and then deleting the subscript from the main global.  Obviously this could temporarily greatly increase the amount of space this global uses; hence the switch to something better.

The global I'm archiving is very large, so I'd like to ensure that this utility doesn't copy the global to a temp global, a PPG, or any kind of format that would take up disk space (aside form the space the file is using).  

Do you know if this utility works directly from the global to the file, or does it use any temp globals along the way?

Thanks,

Laura

Thank you.  Does this count toward the $storage value? or is the $storage affected only by variables (and not PPGs)?

This is one of my favorite posts - and my favorite code snippet that will log an error and return a status:

set ok=$$$OK
try {

}
catch (ex) {
    do ex.Log()
    set ok=ex.AsStatus()
}
quit ok
 

Understood.  I've gone through this configuration before, and set up username/password, and other security.  I don't know why this appears to have been reset for this instance.  But the SM_FORMS setting worked - thanks.

Wow.  That very well could be the cause - SM_FORMS is enabled on another server (a few other differences, but none that seem pertinent).  Is this something I can change on a production server without disrupting users?  They should be going through the IIS ... 

Thank you all, for the comments.  It sounds like there's not too much of a problem keeping the INT code.  The space needed would indeed be smal compared to the space for the datasets.  It doesn't increase privacy or security.  Rather, it sounds more like the INT code is provided for our benefit, for debugging purposes, and is normally not saved on live systems almost out of tradition (and because who is debugging on live, eh? Well, I am, at times).

Thanks,

Laura

I think the frozen plans from our fairly recent upgrade was indeed the problem, especially taking into account what Wolf said about adding new properties to a table.  I had done that recently, which makes the "SELECT-list and INTO-list mismatch" error more plausible. We upgraded to 2017.2.2.

I coudln't really test unfreezing the plan (which was in a Frozen/Upgrade status) because I had already changed the code to use a new object, %SQL.Statement.  And, this also makes sense, since using a new object probably created a new plan ... ?

We are not that sophisticated -- we don't have a DBA -- I'd prefer to let InterSystems code optimize the queries. We never optimize and freeze plans.  We just add Indexes to make queries faster.  I'll probably leave the queries frozen until we come across this problem again.  Unless I hear that it's OK to simply unfreeze them all.  What's the downside to that?

Thanks for the help,

Laura

Update: using the %SQL.Statement class did help, and I had to change only a few lines of code (the Execute, Next, and Data methods).

Still curious as to why this was happening on our DEV server but not other servers, where the other servers still have the original code using %ResultSet class.  And why now -- we've been using this code for years, and upgraded to 2017 in July.

Thanks,

Laura

I have been killing index globals and rebuilding indices (a lot), because I was also changing how I added the Tag.  

/// Add Tag,Tag.Tag as Key, to claim array of Tags
Method AddTag(tag As Data.Tag) As %Status
{
set ok=$$$OK
try {
..TagsArray.SetAt(tag,tag.Tag)
do ..Tags.Insert(tag)
}
catch (ex) {
set ok=ex.AsStatus() 
}
quit ok
}

I had some version of code yesterday where my last query worked, and used the index.  I imagine that we'll be looking for tags based on the "Tag" property (i.e. 'LLC' or 'TWO') rather than the ID, but we could just use the ID.

I can do that.  For future queries, I'm getting these 4 errors in the Audit Database for each error:

Description: Attempt to access a protected resource
Reoutine: EMSUpdatePassword+2^%SYS.SECURITY |"^^c:\intersystems\ensembledev\mgr\"|
Namespace: {namespace}
Event Data: <PROTECT>EMSUpdatePassword+2^%SYS.SECURITY *c:\intersystems\ensembledev\mgr\

Description: Attempt to access a protected database
Routine: Store+5^%ETN |"^^c:\intersystems\ensembledev\mgr\cachelib\"|
Namespace: {namespace}
Event Data: <PROTECT>Store+5^%ETN

Description: Attempt to access a protected database
Routine: Value^%STACK |"^^c:\intersystems\ensembledev\mgr\cachelib\"|
Namespace: {namespace}
Event Data: <PROTECT>Value^%STACK

Description: Attempt to access a protected resource
Routine: ^%SYS.SECURITY |"^^c:\intersystems\ensembledev\mgr\"|
Namespace: {namespace}
Event Data: <PROTECT>^%SYS.SECURITY *$TEXT(EMSUpdatePassword+2^%SYS.SECURITY)

I'll ask IS.

Thanks,

Laura