On the eventlog of the machine where our cluster is located, we get this error:
The description for Event ID ( 1 ) in Source ( VBRuntime ) cannot be found. The local computer may not have the necessary registry information or message DLL files to display messages from a remote computer. The following information is part of the event: Application CTHEJDE: Thread ID: 3612 ,Logged:
Source: CTHEBLC: clsProcessedOrder_T
Module: clsEDIPicker - pProcessEDIFile().
It's obvious that you are running a VB executable either directly on this machine or as a remote in-process OLE coming from another box (I think the latter is most likely). Make sure you have VB run-time library DLL present and registered on your cluster:
Originally posted by azerty74
Thats not it, we have many other comonents on the same machine, who run without any probs, and they also use the vb runtime...
Correct, your VBRunTime is working perfect, since the log event is written by the VBRunTime.
The error number looks like an ADO error, but I was unable to locate it on MSDN. Strange, especially because the error description is UpdateOrderHeader, which doesn't looks like a generic ADO error description. So, I would guess that this error is a user-defined error.
I would dive into the application source of CTHEBLC: clsProcessedOrder_T, and locate the place of generating this error in the module clsEDIPicker - pProcessEDIFile(). If you don't have the source, I would report this log event to the application developer.
Make everything as simple as possible, but not simpler! - A. Einstein
DB Problems? DB Explorer, BTrieve Re-engineering, DB Conversions & ETL? Conversion Tool
Sorry for my previous post. It is, however, a COM exception (you can tell by the negative number). When you throw a COM exception from VB, you are supposed to add the value vbObjectError to the error value (-2147221504), which was apparently done here.
So, you need to subtract that from your error value to get the actual error code, which appears to be 70032. Still a user-defined error, but a bit closer to what you are looking for.
The developer should have the error enum that details all of the error codes. If you have access to VB, you can open a blank project, create a reference to the DLL (tools/references), and open the Object Browser (F2). There should be a list of defined error codes listed under the DLL's globals section (hopefully).
True. If you are calling from SQL, best to make them Extended Stored Procedures. Much more usable as well, as you can treat them like any other SP that way. We even have extended stored procs retrieving data from network devices from around the world. It really opens up a whole new level of coolness.