so mainly you have to work with Iris Class Documentation to find details of the Method Signatures.

If it's a classMethod you can invoke the matching IRIS Method directly, if it's a InstanceMethod you have to invoke %OpenId or %New() to have a Object Handle and invoke Methods on them. 

Invoking the Methods on Iris is straight forward and not complicated - (used to be a pain with Cache); 

Be aware that RefrenceParameters and Results with .Net Interface MAY NOT correspond to IRIS Documentation - actually i can't give you a reliable advice on that.

N.B. Some method just DO NOT WORK with .Net Interface - mainly this are all Methods which produce multiple lines of output if invoked by Iris Terminal (e.g. %ValidateIndices). If i have to invoke a method like that i just wrap them into a userdefined IRIS Helper-Class and invoke this helper class. (you even might declare your user method as SQL Method beeing able to invoke this method by sql)

this is taken from testlibrary - where "Appliance.User" is a custom defined Object. 
Using IRIS and invoking ClassMethod %Library.Pesistent.%OpenId to receive a ObjectReference to the stored object with ID 1. 
Using that ObjectReference i'm able to invoke %ClassName on that object to get the ClassName of that object. 
With tryBlock i'm using same extensions to invoke same helper methods wich encapsulate more classMethods from %Persistent - but that follows exactly same pattern...


using (var conn = ConnectionFactory.CreateConnection() as IRISADOConnection)
{

    var iris = IRIS.CreateIRIS(conn);
    var obj = iris.ClassMethodObject("Appliance.User", "%OpenId", 1 );
    Assert.NotNull(obj);
    
    var iObj = obj as IRISObject;
    Assert.NotNull(iObj);
    Assert.True(iObj.Oref() == "3@Appliance.User");
    
    var clsName = iObj.InvokeString("%ClassName", true );
    try
    {
        var id = iObj.InvokeString("%Id");
        iris.LockId(clsName, id);
        iris.UnLockId(clsName, id);
        
        //iris.ValidateIndex(clsName);
        iris.PurgeIndex(clsName);
        iris.BuildIndex(clsName);
        
    }
    catch (Exception e)
    {
        Console.WriteLine(e);
        throw;
    }

1. like it this way; if you want "net" property access you have to generate proxy classes which wrap the mentioned methods...

2. InterSystems.Data.IRISClient.AD.IRISObject  is in Assembly InterSystems.Data.IRISClient, maybe dll not matching framework version? (umpf, sorry didn't read that you're on 2019... don't know about that)

found out about the second; That only affects raw Globals without ClassDefinition...

Obviously a problem of how "Types" are constructed; partly they're embedded in the data; partly it's part of the ClassDefinition?

So just guessing; The problem with storing decimal values is because at the level inserting data via IRISList you don't have info about the Scale-Factor - does this make it impossible to store data internally?

thanks; that did the job...

... and i guess you're right with what you say - for my perspective this behaviour is somehow strange; Shouldn't then InterSystems add a "dummy device" on calling methods to avoid these kind of exceptions? 

Never before i had a problem like that calling e.g. LoadMethod and for my sight it's a bit irritating that InterSystems expect me to know if a method i'll call will write to a "not allowed device" and to investigate how to trick that away 

Hi Raj, on writing test code for you i noticed that this might be a "interpretation" problem.

I assumed that - as son as the transaction is started - the property IsTransactionActive will be true. In Fact this property is True only after the first Transaction is executed. 

It would be very practical if i could detect from a connection if a Transaction was started - Additionally i'd like to have  access to the IrisTransaktion on the Connection itself - would make programming very much easiere....