You can use Apache POI library (or call PS, but cursory googling shows that Word is a requirement via COM objects) for example to get this information. As for how explorer gets doc info - I have honestly no idea.

Docker for windows allows switching between Linux containers and native Windows containers; if you want to use Linux containers (i.e. IRIS), make sure you enabled that mode

See this section in the documentation.

What's VB got to do with this?

Looks like a locale problem.

Add to the beginning of the script:

import locale
locale.setlocale(locale.LC_ALL, 'en_US.utf8')

What error are you executing?

What error are you getting?

%ALLINDEX maybe. Also check alternate plans.

Can you show an example:

• your table definitions
• your query
• your plan
• how do you think plan should go?

Commit triggered a recalculation.

1. Modern editors color variable based on scope. p/t in the beginning is unnecessary.

7. I mean if you develop an API all methods should accept either primitives or ByRefs or json. Not object arguments in one method, primitives in another, etc.

8. If you return %Status always return it. If you return $this always return self.

9. If your class has several instance methods and each has, let's say "debug" argument, remove this argument from methods and add "debug" as a class property.

what are you doing there?

Coding.

1 namespace == 1 project.

SQL is a declarative language (same as HTML for example). It does not DO anything. All it is is a description of what do you want to achieve. 

In the case of InterSystems IRIS (and any other dbms for that matter) we take SQL statement, parse it into AST and generate code in other imperative language from AST. Now this generated code gets executed.

In case of InterSystems IRIS we generate the code in ObjectScript language. For DROP statement it would include  this line:

kill ^globalD

If you want to you actually can see generated OjectScript code. To do that

Open SMP > System Administration > Configuration > SQL and Object Settings > General SQL Settings.
Enable "Cached Query - Save Source" — This specifies whether to save the routine and INT code that Caché generates when you execute any Caché SQL except for embedded SQL.

After that purge query from portal if it already exists and execute the query again in SMP.

You'll see something like this:

Cached query %sqlcq.<NAMESPACE>.cls<NUMBER>

Go to studio and open %sqlcq.<NAMESPACE>.cls<NUMBER> class - it would contain generated ObjectScript code that executes for your SQL query.

Set ^%SYS("zenreport","excelserverport")=5005

Great points, Sean.

However there are, I think, areas where macros are needed:

• Compile-time execution (if it's possible to resolve stuff at compile time, do it)
• Constants/Enums
• Trivial wrappers over system functions (i.e. I use $$$ts instead of $zdt($h, 3, 1, 3) because it's everywhere)

But I definitely agree that overabundance of custom macros makes code unreadable.

Let's say you created class Point:

Class try.Point Extends %Persistent [DDLAllowed]
{

Property X;

Property Y;

}

You can also create it via DDL:

CREATE Table try.Point ...

It would create the same class.

After compilation our new class would have autogenerated Storage structure which is a mapping of global to data to columns and properties:

Storage Default
{
<Data name="PointDefaultData">
<Value name="1">
<Value>%%CLASSNAME</Value>
</Value>
<Value name="2">
<Value>X</Value>
</Value>
<Value name="3">
<Value>Y</Value>
</Value>
</Data>
<DataLocation>^try.PointD</DataLocation>
<DefaultData>PointDefaultData</DefaultData>
<IdLocation>^try.PointD</IdLocation>
<IndexLocation>^try.PointI</IndexLocation>
<StreamLocation>^try.PointS</StreamLocation>
<Type>%Library.CacheStorage</Type>
}

What is going on here?

From the bottom and up (bolded are important, ignore the rest):

• Type: type of generated storage, in our case the default storage for persistent objects
• StreamLocation - name of global where we store streams
• IndexLocation - name of global for indices
• IdLocation - name of global where we store ID autoincremental counter
• DefaultData - name of storage XML element which maps global value to columns/properties
• DataLocation - name of global to store data

Now our default data is PointDefaultData so let's see it.  Essentially it says that global node has this structure:

• 1 - %%CLASSNAME
• 2 - X
• 3 - Y

So we might expect our global to look like this:

^try.PointD(id) = %%CLASSNAME, X, Y

But if we output our global it would be empty because we didn't add any data:

zw ^try.PointD

Let's add one object:

set p = ##class(try.Point).%New()
set p.X = 1
set p.Y = 2
write p.%Save()

And here's our global

zw ^try.PointD
^try.PointD=1
^try.PointD(1)=$lb("",1,2)

As you see our expected structure %%CLASSNAME, X, Y is set with $lb("",1,2) which corresponds to X and Y properties of our object (%%CLASSNAME is system property, ignore it).

We can also add a row via SQL:

INSERT INTO try.Point (X, Y) VALUES (3,4)

Now our global looks like this:

zw ^try.PointD
^try.PointD=2
^try.PointD(1)=$lb("",1,2)
^try.PointD(2)=$lb("",3,4)

So the data we add via objects or sql is stored in globals according to storage definitions (you can modify manually storage definition by replacing X and Y in PointDefaultData  - check what happens to new data!)

Now, what happens when we want to execute SQL query?

SELECT * FROM try.Point

It is translated into ObjectScript code that iterates over ^try.PointD global and populates columns based on storage definition - PointDefaultData  part of it precisely.

Now for modifications. Let's delete all the data from the table

DELETE FROM try.Point

And let's see our global after it:

zw ^try.PointD
^try.PointD=2

Note that only ID counter is left, so new object/row would have an ID=3. Also our class and table continue to exist.

But what happens on:

DROP TABLE try.Point

It would destroy the table, class and delete the global.

zw ^try.PointD

Classes and tables are mappings that are read "on the fly". That's exactly it.

Stores data on disk? Meaning, that if we create these persistent classes, the data is stored twice? Once in the global node and in some other format as defined (or not defined by the class)?

The data is stored in globals and only globals. Globals themselves are physically written on disk.

But just to reiterate, how does the DDL interpret a read definition into a write definition? The data stored in the global node and the definition do line up exactly (in our case, almost not at all).

Please expand your question. Do you mean how does SELECT or DROP or whatever SQL statement against table interacts with globals?