AllAccepted answers
Joel Solon · Mar 25

A little bit more detail. The queries in %SYSTEM.License are not defined as [SqlProc]s. Therefore, they can't be called from outside IRIS, including from Python. To get the information returned by these queries in Python, you should write your own method in ObjectScript, that runs the query with the (deprecated) %Library.ResultSet class. As you loop through the results:

Joel Solon · Mar 17

...and it appears that Mr C is also trying to sneak in a new abbreviation for ObjectScript: ISOS. indecision

Joel Solon · Jan 4

Ah, I misinterpreted "this alias" in your post! So you meant (I added italicized text): "I like to define :sql as a way to launch the shell and execute a statement - so that means this built-in :sql alias should be renamed by InterSystems to something else!! or be removed."

At least aliases defined in .iris_init override any built-in aliases.

Joel Solon · Jan 4

I have one older IRIS instance (unreleased v2021.1 with some Python extras) that has the following aliases built in. The :sql alias doesn't run Execute() like it seems to do on yours.

:py          Do $system.Python.Shell()
:mdx         Do $system.DeepSee.Shell()
:sql         Do $system.SQL.Shell()
:tsql        Do $system.SQL.TSQLShell()
Joel Solon · Jan 3

Here's some info that was inadvertently removed from the docs, but will be returning soon:


On Unix systems, if a file named ~/.iris_init exists, it is read when a terminal session is initiated. Only lines starting with :<command> are processed. All other lines are ignored. This file accepts only :alias commands, which enables you to store favorite command abbreviations there.
Example of a ~/.iris_init file:

# Initial aliases
:alias %  zn "%SYS"
:alias load Do $System.OBJ.Load("$1",$S("$2"="":"ck",1:"$2"))
:alias ut Do ##class(%UnitTest.Manager).RunTest("$1")
Joel Solon · Dec 30, 2021

:alias sql do $system.SQL.Shell()

:alias err do $system.Status.DisplayError($1)

Joel Solon · Dec 29, 2021

VS Code - ObjectScript doesn't prevent <SUBSCRIPT> errors. For example, the statement

set b(x) = c

can't be checked by the IDE since it doesn't know if the value of x will be "" or not at runtime.

Joel Solon · Dec 21, 2021

Nice article about an important question: when should you touch the storage definition? Some comments on the scenarios (with sound effects!). The only modifications I'd make to the bookshelf analogy is that there are gazillions of shelves (every person gets their own shelf) using the mapping of what type of book goes in each slot.

  1. Scenario 1: You are creating a class, and adding, deleting, and renaming properties. If there's any data for the class, it is test/temporary data and can be deleted at will. As Vivian saw, deleting a property doesn't change the storage definition (the slot for the deleted property is left unused), and renaming a property is really a deletion (old slot unused) followed by an addition (new slot). Once you get the class the way you want it for release, you can safely delete the storage definition (since there's no real data) and the next compilation will create a fresh one, with no unused slots. No danger (cue happy music).
  2. Scenario 2: You are editing an existing class with real stored data. If you rename any property (new or existing, with or without data) it's best practice to rename the storage definition slot also before your next compile. If it's a newly added property without data and you don't bother to rename the slot, it's OK, but you now have a wasted slot that will never be used, and a new slot for the data you'll eventually start saving. Why not rename the slot right away? On the other hand, if it's a property that has data, you must rename the storage slot, or the data for that property will no longer be accessible, and new data for the renamed property will go in a different slot. Any danger is prevented by renaming the property and storage definition slot at the same time (cue triumphant marching music).
  3. Scenario 3: You delete a property with real stored data. As before, the old slot is left unused. Any new property added later will not use that slot (no double-booking; new data won't ever be added there). But the real question is: Why are you deleting the property? Do you not care about that data anymore? If so, why aren't you deleting the data first? And by deleting the data, I don't mean editing the global directly (which I think is what Vivian meant by "don't do this."). But it's not dangerous to the table to use SQL to delete Book B from every bookshelf before deleting the property:update schema.table set property = null(cue computer bleeps).

Editing the name of any unused slot in the storage definition and adding "-unused" to make things clear could be OK but it's definitely not intended for that use. I'm not sure it's necessary to do anything in this case; If I see a slot in the storage definition named XYZ and there's no property XYZ, I know it's an unused slot. Maybe preceding the storage definition with a comment section would be cleaner:

/* unused slots
   XYZ (as of 1/1/2020)
   ABC (as of 6/1/2021)
*/

Please let me know if it's not clear, or if I missed a scenario.

Joel Solon · Nov 10, 2021

I added Steve's suggestion, not because he asked twice, but because I owe him some money. wink