Re: Unexpected return value for GetAccessControlDetailsEx in COM API (657 Views)
Occasional Contributor
Posts: 5
Registered: ‎01-18-2012
Message 1 of 6 (743 Views)

Unexpected return value for GetAccessControlDetailsEx in COM API

Hi Folks,


I'm having some issues getting Access Control information from TRIM Records using the COM API. The GetAccessControlDetailsEx method is not returning what I expect it to return (a collection of Location objects).


We're using a Java-COM bridge (jinterop), which is working fine for everything except our calls to GetAccessControlDetailsEx and GetAccessControlDetails on any TRIM Record object. Instead of getting back a collection of Locations with access, we get back a collection of locations that contains the database object. I realise using the Java-COM bridge adds complexity, but the rest of the COM API is behaving as expected.


Does anyone have any suggestions for troubleshooting/solving this problem? Is there a known bug in the COM API around this stuff? I can't find much info online about working with the Access Control Information.


FWIW, a colleague coded up a quick bit of C++ to test the COM API natively (see attached). In this case, getAccessControlDetailsEx returns null, which also seems unexpected.


As a workaround, I am currently extracting human-readable access control information from the 'AccessControl' property on the Record. This, however, requires parsing the returned string, and pulling out the correct users/groups using regular expressions, which is a much more brittle solution.


Thanks in advance for any help you can offer!




Occasional Contributor
Posts: 5
Registered: ‎01-18-2012
Message 2 of 6 (742 Views)

Re: Unexpected return value for GetAccessControlDetailsEx in COM API

Should add that this is running against TRIM I realise that .NET is the preferred API for this version, but we also need to run the code against a production 6.x instance - hence using the COM API.
Trusted Contributor
Posts: 242
Registered: ‎03-31-2010
Message 3 of 6 (735 Views)

Re: Unexpected return value for GetAccessControlDetailsEx in COM API

could you post your bit of code surrounding the GetAccessControlDetailsEx code, (not being familar with c++ i can't spot why your colleagues code gets nulls which is different to what you get which shows the Db anyway)


you can run .net api code against a 6.2.x dataset, if its being run from a box with 7 installed, so if you can install 7.x on a server and use that to connect to your 6.x and 7.x datasets that could be an alternative, or maybe I misundestood your requirements ...



Occasional Contributor
Posts: 5
Registered: ‎01-18-2012
Message 4 of 6 (732 Views)

Re: Unexpected return value for GetAccessControlDetailsEx in COM API

Hi Rich_Kid,


Thanks for your response. I'm happy to post the relevant code, but bear in mind that it's Java code using jinterop to call down to the COM API. Also, I've got a whole library that basically wraps the COM API with a Java API (hence the references to classes like TRIMLocation and TRIMLocations). This is all working fine for everything except the AccessControl info.


Here's the Java code in question:


public Pair<Integer, TRIMLocations> GetAccessControlDetailsEx(int accessControlType, TRIMLocations locs) throws JIException{

JIVariant[] args = {
JIVariant.makeVariant(0, true),
JIVariant.makeVariant(locs.dispatch, true)


// This returns the human readable ACL string fine
System.out.println("Access Control: "+dispatch.get("AccessControl").getObjectAsString2());


// This does not return the expected collection of Locations.

// Instead it returns a collection with a single COM object that

// represents the database (e.g., with id=45 and name=DemoDB,

// when run on the DemoDB)

JIVariant[] rets = dispatch.callMethodA("GetAccessControlDetailsEx", args);

int accessSetting = rets[2].getObjectAsInt();

IJIDispatch d = (IJIDispatch)JIObjectFactory.narrowObject(

TRIMLocations accessLocations = new TRIMLocations(d);

return new Pair<Integer, TRIMLocations>(accessSetting, accessLocations);


Unfortunately, I need this to integrate with other Java code, so .NET is not an attractive option at this stage. I also don't have the option to upgrade or install alternate TRIM versions on the production TRIM server. My main aim is to try to uncover why the GetAccessControlDetailsEx call is not returning what I expect.


Thanks again for your ideas, Rich_Kid. Looking forward to hearing any other suggestions you and the rest of the TRIM community are able to offer.


Honored Contributor
Posts: 1,960
Registered: ‎04-20-2010
Message 5 of 6 (711 Views)

Re: Unexpected return value for GetAccessControlDetailsEx in COM API

I haven't coded Java in ages, so am not sure how you handle sending objects by reference.  The third parameter of the method should be sent by reference or pointer.  But it looks like you're trying to take the return value from the method instead, and then convert that into a Locations collection by instantiating a new object.  


Or maybe I'm off base here.  

Occasional Contributor
Posts: 5
Registered: ‎01-18-2012
Message 6 of 6 (657 Views)

Re: Unexpected return value for GetAccessControlDetailsEx in COM API

Thanks for the suggestions, and apologies for such a delayed response - it seems my original response never actually posted (which may explain the lack of further input!)


The pass-by-reference is handled by jinterop, and is effected by the 'true' argument passed to JIVariant.makeVariant(). The creation of the Locations object is really just a cast (of sorts) to process the response. Being Java, the method parameter isn't passed by reference within Java, so the response is wrapped into a return array by jinterop. This method of interacting with pass-by-reference parameters is working for all the other TRIM API calls I'm using with jinterop - except this GetAccessControlDetailsEx.


Thanks again for taking the time to make constructive suggestions!

The opinions expressed above are the personal opinions of the authors, not of HP. By using this site, you accept the Terms of Use and Rules of Participation.