BUG : Database Connectivity Toolkit 1.0.2 masks errors

[Matthew_Kelton]

I have been working around this bug for a while but finally got fed up with it today and tracked down the culprit.

The Database Connectivity toolkit can mask an error if you are doing multiple transactions and you are counting on the VIs themselves to handle an error in the error cluster.

In the VI, Conn objectRepository.vi , part of NI_Database_API.lvlib, the VI will mask an incoming error if an error occurs.  What you will find is you will get an error 1 from an invalid object which has nothing to do with the error your code generated.  This is due to the miswiring of the Error Merge VI which puts preference to the VI's error over the incoming error cluster.  I believe the error being generatingby my code is causing the occurence reference to be invalid along the line, because the error 1 always occurs when I try to destroy the connection reference.

The fix is to modify the VI to swap the error cluster wiring so the incoming error has preference over the VI's error cluster.  See the picture below.

 

Message Edited by Matthew Kelton on 02-11-2009 01:20 PM

[tst]

Well, I actually feel this is a general problem with the merge errors VI, in that it doesn't actually merge errors, but simply takes one of the errors that comes into it and loses information if it has more than one error.

Another side point is that the calling VI doesn't use the convention of not executing its code if it has an incoming error, but since I can't look at it at the moment, I can't say whether that behavior is correct or not.

[Matthew_Kelton]

Unfortunateky, that is a limitation of the system.

I can understand still running code even if an incoming error occurs.  I do that when I am closing references, files, etc. so that they close regeardless of the error condition.  I then use the Merge Errors vi to let the incoming error take precedence over any error geenrated by the cleanup code.  The issue here is that they let the code's error take precedence.  Since an incoming error could mean that the code running may not function properly, you have to let the incoming error take precedence.

This masking actually only appears to occur if the error occurs before the recorset reference is created (I usually see it on a second loop iteration), so it appears the reference doesn't get created when an incoming error is there (which I would expect), but then they pass out the error from trying to close an invalid reference, which makes no sense.

[Hueter]

Matthew

Thank you for reporting this. The error priority makes this VI harder to debug, and I agree the errors should be switched. I have filed a Corrective Action Report (CAR) with the LabVIEW R&D Team. Hopefully this will be fixed in a future version and in the meantime the workaround is simple, just swap the errors yourself.

For future reference this is CAR #146185

Thanks

Hunter

[Matthew_Kelton]

It appears that the error handling problems are not just associated with this VI:

http://forums.ni.com/ni/board/message?board.id=170&thread.id=402797

 Here, internal counts are not being properly handled in error situations.