New post
AllAccepted answers
Robert Cemper · May 22, 2019

as you describe if you refer to a file outside Caché and Caché has no control over it
it's a clear case of data inconsistency

you have 4 options:
1a) create a fake file at that reference an delete it then

1b) add an "on before delete" trigger to check and fix in advance either in the record or  in file system 

2a) manipulate the file reference using the object behind your entry

2b) do the delete at object level, trap the error and ignore it. since the file is gone anyway 

Robert Cemper · May 14, 2019

In fact, I see not 1 but 2 tables that share the same global.

so it might be easier to have 2 separated definitions one with and the other without the  4th subscript (some $h)

for access with SQL you than can use a UNION to assemble them. like:

SELECT * FROM (
     SELECT Account, PGC, Entity, ' ' as DateTime, ..fields... FROM TAB1 WHERE <some condition >
     UNION ALL
     SELECT Account, PGC, Entity, DateTime, ..same as above... FROM TAB2 WHERE <same condition >
) order by 1,2,3,4

or  you decide to add the missing subscript in your global to have a common structure

Robert Cemper · May 8, 2019

If this is Caché standard ID it is projected to SQL as xDBC Type INTEGER
Caché SQL Reference - Data Types says:

INTEGER%Library.Integer (MAXVAL=2147483647, MINVAL=-2147483648)

so 5983658923646 is definitely out of range

xDBC Type :

BIGINT

%Library.BigInt

   represents a 64 bit integer value.

I'm not aware of any parameter to change the data type of the generated ID.
But this hack may do the trick. Just add this calculated Property to your class without affecting the storage.

Property myID As %BigInt [ Calculated, SqlComputeCode = { set {*}=%ID}, SqlComputed ];
 

Robert Cemper · May 6, 2019

At first sight in Documatic, it  looks like 

 %Library.CacheStorage

 was just renamed to  

%Storage.Persistent

As a workaround, I would simply try in Caché to make a copy of  %Library.CacheStorage to a new %Storage.Persistent
(a pure rename)  Then compile a class with one and the other and compare the generated .int code.

It's a dirty hack. frown
But I have no hope ISC will ever provide some backward port from IRIS to Caché.

Sorry I have no IRIS at hands and can't try it myself.

Robert Cemper · May 5, 2019

score

-1  #1 - disagree, see no valid reasoning

-2  #2 - strongly disagree

-1 #3 - disagree because of #2

+1 #4- agree

+1 #5 - agree

+1 #6 - agree . pls.send enhancement req. to engineering

+0 #7 - not clear about the message ? an oref is neither primitive nor dynamic

+0 #8 - miss imagination of inconsistent return types

+0 #9 - don't understand that message
 

Robert Cemper · May 2, 2019

It's really a matter of taste.

If you don't like the long list of params (especially with lousy documented methods) you can

#1) use 1 single param and pass a local array byRef .  and decode it yourself eg:

par("IPadrr")="127.0.0.1")
par("Port")=1972
par(Namespace")="SAMPLES"
.....

do  ##class(my.par).method(.par)

or

#2) use the traditional style you may know from Caché I/O Device Guide  having also just 1 parameter

do  ##class(my.pieces).method("/SERVER=127.0.0.1:/PORT=1972:/NAMESPACE=SAMPLES")

I personally prefer #2) as it gives you an embedded doc on your intentions.

Robert Cemper · Apr 29, 2019

#1) all documentation on XML is here

It covers everything to output Objects to XML.

#2) to fill  this in-between object you may use the SQL Table represented by an object class.
 as simple INSERT  INTO  my.xmltable select .........

You just have to take care that the object class also extends %XML.Adapter .
That makes it ready for XML Export.  All details described in docs  

Robert Cemper · Apr 26, 2019

Dear Martin,

I have a rather clear vision  where your $example comes from ($zzg, $zza, ...)  wink
My personal suggestion is to move everything you maintain today in %ZZLANG?00 routines into clean Macro definitions (.inc)

The history of %LANG* code goes back to times when migration from other language dialects (MSM, DTM, DSM, VISOS, ..) happened
and developers were writing just in  .INT routines. That's far back in the late 80ies.  The availability of MACRO code (also ages back) made it almost obsolete. The feature was never eliminated by considerations of backward compatibility. 

I personally would never allow any developer to touch %SYS. 
And wouldn't accept any code using $zz* , zz* stuff or $zu().
There are much cleaner ways to achieve the same result without compromising the core. 

Robert Cemper · Apr 19, 2019

I may misunderstand your intentions but

when I use "ResultSet.%Get("Collection")", all I get is a list of the primary keys of the objects. 

now you all you miss for each PrimaryKey is 

Set collB=##class(ICT.Experiments.B).%OpenId(primaryKey) 

or

Set collC=##class(ICT.Experiments.C).%OpenId(primaryKey)

and the object is yours.

With your class definition,  PrimaryKey is the Idkey of the Object.