Fetch NAV ERROR('') in .NET COM

Is your "aw" var global? Try to make it private. (Then the CLEAR command is also not needed anymore).
It is also always a good idea to use local vars, if possible.

Perhaps you could make the class IDisposable.
In the Dispose() you can release your allocated objects by hand.

wakestar wrote:

Hi

I would expose a com - event for CLR exceptions and pass the Exception - Message to Navision.

In Navision it should look like this:

MyControl::ExceptionThrown(Exception: Text[1024])
MESSAGE(Exception);

This way you can avoid calling "IF NOT GetBeer(1,cold)" a zillion times and you can implement the logic for the errors in Navision instead in your .net assemby.

Navision Errors are COM errors and the CLR throws them as COMExceptions.
So you can try to catch exceptions in .Net and fire an event in Navision, for example ClearObject which should look like:

MyControl::ClearObject()
CLEAR(MyControl);

and take a look at COMtrace which is helpful when you mess around with COM
http://www.blunck.se/comtrace/comtrace.html

wakestar

I don't think this will solve his problem because from my point of view the problem is related to the ADO object being still in use if he raises a C/SIDE error (which will result in a dispose of the wrapper). This leads me to the conclusion that the dispose of the wrapper is not sufficient and he has to cleanup inside .NET.

todro wrote:

I don't think this will solve his problem because from my point of view the problem is related to the ADO object being still in use if he raises a C/SIDE error (which will result in a dispose of the wrapper). This leads me to the conclusion that the dispose of the wrapper is not sufficient and he has to cleanup inside .NET.

Hi
I have no idea how his .net code looks like, but yes... he's responsible for cleaning up the resources used within his .net class.

The last .net component I made was one single .net form which I'm closing when an en error happens. After the this.close() I fire the ClearObject in Navision. - The this.close() does it for me in my case. - I never had any problems with the GC.

jwikman wrote:

todro wrote:

I don't think this will solve his problem because from my point of view the problem is related to the ADO object being still in use if he raises a C/SIDE error (which will result in a dispose of the wrapper). This leads me to the conclusion that the dispose of the wrapper is not sufficient and he has to cleanup inside .NET.

I think I agree with you... I can make the cleanup inside .NET. But, as I wrote earlier, the disposal of the wrapper isn't equal to the disposal of the .NET component. The cleanup in the .NET component is done too late due to the logic of Garbage Collecting in .NET.

Yes, I know what you are talking about but let's have a look at a transaction

1.) you create aw in C/SIDE which causes a CCW to be created via .NET COM Interop
2.) you run a function within the wrapper which might return an error
3.) regardless of whether you raise an ERROR in C/SIDE or simply display a message, the ADO connection has to be released before you continue in Navision with the ERROR or you have to call a "ClearADO" function inside the wrapper before raising the error in Navision.

Now the question:

Why don't you close the ADO connections by running a cleanup function in the wrapper from within Navision ?

aw.closeconnections();
ERROR('...');

Maybe I got something wrong, but let's mak sure we are talking about the same thing.

I only see one situation where you run into problems: if an unexpected C/SIDE runtime error occures, all existing ADO objects (and connections) are alive until the garbage collection of .NET destroys the CCW referenced object.

If I read your original issue correctly - the problem arrises in Navision if you encounter a problem/error after you have started the transaction in the external COM/.Net component. Here is an alternative solution to the proposed VB6 Wrapper

I would use 3 different objects:
1) Calling Object (table,codeunit, form, etc. where thread of execution starts)
2) Transaction Codeunit (calls the Component Wrapper and may encounter error conditions)
3) Component Wrapper Codeunit(a single instance codeunit which has functions that expose the logic of the component to Navision)

Calling Object Code:

//assume WrapperCDU and TransCDU are codeunit variables
WrapperCDU.StartTrans;
if not TransCDU.run then begin
  WrapperCDU.AbortTrans;
  WrapperCDU.CleanUp;
end;

I am assuming that there is some "StartTrans", "AbortTrans" and "CleanUp" functions in the Component Wrapper Codeunit that can be used to start/abort a transaction as well as clean up the connection. This would allow you to address your original problem of a left over connection without the need of a VB6 wrapper.

While this may also be a bit of a hack - you should be able to do away with your VB6 wrapper class and only have to maintain .Net code and Navision code. I've found as you add layers of complexity it becomes more difficult to maintain and support.

Just on wondering why you have an aversion to Single Instance Codeunits? Have you had problems with Single Instance Codeunits in the past? If so what were the specifics?

As far as doing everything in Nav...I still have a love/hate relationship with Navision. I recognize the power of it and the structured development environment can help....but I definately miss the full on power of a true development environment like .Net