ActiveX DLL import not working

[isabpf]

I'm working with VB developers to import their ActiveX DLL functions into DataStage, and in following the instruction manual we've done the following:
1. Placed DLL file on Ascential server
2. Registered it to the server
3. In DSManager, selected Import External Function Definitions
4. Browsed to the file, selected it and hit <next>
At this point, we get a message stating "Error accessing the OLE registry".

After reading other threads from here, I verified with the VB coder that this is a function and not a subroutine (it is). Does anyone have an idea of what we're missing?

Thanks for your help, Bryan

[arronharden]

You could try checking the userid used to login to the DataStage server has write access permission to the HKEY_CLASSES_ROOT & HKEY_LOCAL_MACHINE registry keys on that server (use right-click in regedt32.exe to check).

If they don't you can either explicitly add them to the keys permission list or add them to the administrators group on that machine.

- Arron

[isabpf]

Arron, that was exactly the problem, and we got the import to work. Thanks for your very timely help!

[ds_developer]

Now that you have the functions imported you should watch for the following problem:

If you have output parameters in your functions, this version of DataStage will not code them as output, but only input.

This is related to the following lines in the ActiveX routine that DataStage made:

ARGTYPES = DSOLE.ATYPE.STRING : DSOLE.ATYPE.STRING : DSOLE.ATYPE.STRING : DSOLE.ATYPE.STRING : DSOLE.ATYPE.STRING

CALL $DSOLE.Dispatch.Method.5Args(SNAME, MNAME, RETTYPE, Ans, ARGTYPES, Arg1, Arg2, Arg3, Arg4, Arg5)

Return(Ans)
*****
FIX:
Change the ARGTYPES assignment to the following:
ARGTYPES = DSOLE.ATYPE.STRING : DSOLE.ATYPE.REFSTRING : DSOLE.ATYPE.REFSTRING : DSOLE.ATYPE.REFSTRING : DSOLE.ATYPE.REFSTRING

If a parameter is output it should be: DSOLE.ATYPE.REFSTRING
If a parameter is input it should be: DSOLE.ATYPE.STRING

This example has 5 parameters, the first is input and the next 4 are output.

Hope this helps.

John

[isabpf]

Thanks John for that additional info -- I've passed it on to the VB'ers to have as they continue their development.

I have to ask another question about our importing though. These same VB'ers are moving to .NET from VB6, and they have created another dll, this time in .NET, for us to import. We used the same process and authority that Arron helped us with, and what worked for the VB6 dll fails for the new dll ("error accessing the OLE registry").

It seems that it's security-related again, but I promised I ask and see if anyone had other thoughts. Thanks again!
Bryan

[arronharden]

Hi,

I think the problem is that Datastage is looking for an embedded type library in the ActiveX dll (it appears as a Win32 resource in the dll) to determine what classes and types are available in the dll.

With VB6, a type library is embedded automatically into ActiveX dll's so no problem.

This has changed in VB.NET (well .NET in general) - There is a different way of describing classes and types etc, so an old COM-style type library is no longer embedded into VB.NET dll's when they are built, even if the classes are marked as COM visible, and the project is set to be registered for COM interop. When Datastage examines a dll built with .NET it can't find any type library so it can't determine what classes etc are in the dll.

I can't see any option in the Visual Studio IDE to embed a COM type library in the dll, but you can do it manually (pretty messy though) if you follow the 'To embed a type library as a Win32 resource in a .NET-based application' instructions on this MSDN page: http://msdn.microsoft.com/library/defau ... forcom.asp

Might be best to stay with VB6 COM until Ascential has .NET component support.

regards, Arron