err.source in a VB ADO project is machine specific

What about OS? Maybe one is Win98, the other WinXP?

Both are Windows XP.

If some object of ADO raises error, then the error source should be the name of the object. This is what I am getting on many machines. But, on one machine, the name of the VB project itself is coming as the name of the error source. I would like to know the reason for this.

avinash_sahay,
How did you check that they are running the same version of MDAC?

Dabas

From MSDN I downloaded component checker. Using it, I checked the versions of the MDAC dlls in the two machines.

Would you mind pasting the code that includes a message to the user as to what err.source is?

I wrote the following code. As you can see, the code executes a select query, which returns rows from emp table of inst1 database having sal < 0. But there is no such row. That is why MoveFirst raises error. Inside error handler, the message box displays the name of the project in one machine, which is unexpected.
Please note that I get the same problem even if I use some provider other than OraOLEDB.Oracle. I have tried with Microsoft's OLEDB provider with the same effect.

On Error GoTo ErrHandler
Dim objCon As New ADODB.Connection
Dim objCmd As New ADODB.Command
Dim objRst As ADODB.Recordset

objCon.Provider = "OraOLEDB.Oracle"
objCon.Open "inst1", "scott", "tiger"
Set objRst = objCon.Execute("Select * from emp where sal < 0")
objRst.MoveFirst
Exit Sub
ErrHandler:
MsgBox "Error source: Err.Source" & ", Description: " & Err.Description

OK. The problem has nothing to do with MDAC
Err.Source is not coming from the ADO error collection but from the VB runtime.
Can it be that the system that is different has a different VB runtime installed? A different SP?

Dabas

Correction: The line starting with MsgBox is:-

MsgBox "Error source:" & Err.Source & ", Description: " & Err.Description

Yep. I figured that out.
Err is not an ADO object, it is a VB object

I also suspect VB. The sample program I have given here is very small. In reality, the test cases contain large number of huge VB projects. When I found the behavior as different in two machines, then I started finding the cause of the problem and ultimately wrote a small sample code pasted here. This way I could eliminate various possibilities.

After this I suspected VB. I did not think of SP, but that also could be a possibility. But I cannot just try reinstalling VB and SP in that machine. This is because the machine on which this problem appears is in a different country. The owner of the machine has given me access to it through VNC. I do not permission to reinstall anything in that. I will have to email him to do so.

But before I email him to reinstall VB, SP, I want to be sure that this will really solve the problem. Because, otherwise, I will to keep telling him to try various options. But this will not look good.

Yes, it is true that Err is a VB object. But still if one VB exe uses a component (e.g. ADO) and that component raises an error to the exe, then Err.Source inside exe is the name of the component.
After all, EXACTLY the same sample code in one machine gives the name of the VB project as Err.Source and in another machine it gives the name of an ADO object.

avinash_sahay,
The sample code does rely on the VB runtime that is in use. The same error happens because it is in the sample code.
But when the program gets to Err.Source, then it calls a function in a dll that belongs to the VB runtime and if you have different VB runtimes then you may get different results.

Are you able through the VNC to have a look at the VBRuntime on the other machine? Compare its version to yours?


Dabas

Both machines have VB 6.0. Anyway, I will check the version of VB runtime dll.

avinash_sahay,
> Both machines have VB 6.0
yeah. but with SP?

Dabas

I checked the version of msvbvmdl.dll. Both machines have the same version. Will check SP now.

This comes out of VB Help

-----Start of Quote--------
Getting Information About an Error
You can't handle an error until you know something about it. Where you get information about an error depends on what caused it. The two main sources of information about errors are the VBA Err object and the ActiveX Data Objects (ADO) Error object. The VBA Err object provides information about VBA errors. The ADO Error object and Errors collection provide information about data-provider errors that occur when ADO objects are being used to access data. Errors that occur in ADO itself, as opposed to the data provider, are reported to the VBA Err object.

----

It looks like in your case the VBA error object is called instead of receiving the data from ADO Error object.
If you are already at it, compare any ADO related dll (I know you have checked MDAC, but just see if the ADO dlls match in version too)

Dabas

I checked in About dialog of Visual Basic editor. Both machines have SP6. Now, I will check ADO dlls. But, if dlls of MDAC have same version, is it possible for ADO dlls' versions to be different?

What are the two error messages and the source objects?  Is it possible you have two different Oracle drivers on the two machines?

Have you the latest version of MDAC?

Both machines have same version of MDAC. Also both have same Oracle drivers. I get the problem of different Err.Source even if I use Microsoft's OLEDB provder.

avinash_sahay,
YOu say both machines have the VB editor.
Do both machines differ in the error when run from the VB editor?

Dabas

>>But I do not understand why err.Source is different on different machines.<<
Lets back up a bit and understand the situation.  You say you have tested the following code:

On Error GoTo ErrHandler
Dim objCon As New ADODB.Connection
Dim objCmd As New ADODB.Command
Dim objRst As ADODB.Recordset

objCon.Provider = "OraOLEDB.Oracle"
objCon.Open "inst1", "scott", "tiger"
Set objRst = objCon.Execute("Select * from emp where sal < 0")
objRst.MoveFirst
Exit Sub
ErrHandler:
MsgBox "Error source:" & Err.Source & ", Description: " & Err.Description

And on two different machines you get a different result for Err.Source. On some it is ADODB.Recordset and on others ADODB.Connection.

Is that correct?

If the answer is yes, than the only plausible answer is that the Err.Description is different in either case. Note:  I am only referring to the sample code above.

If in production code the Err.Description can be the same, yet the Err.Source can be different.  For example, if I run the above code without the Oracle provider, I get the following Err.Description (with an Err.Source of ADODB.Connection):
Provider cannot be found. It may not be properly installed.

Now if I change the above code to the following I get exactly the same error, but a different Err.Source (ADODB.Recordset):
On Error GoTo ErrHandler
Dim objCon As New ADODB.Connection
Dim objCmd As New ADODB.Command
Dim objRst As ADODB.Recordset

'objCon.Provider = "OraOLEDB.Oracle"
'objCon.Open "inst1", "scott", "tiger"
'Set objRst = objCon.Execute("Select * from emp where sal < 0")
Set objRst = New ADODB.Recordset
objRst.ActiveConnection = "Provider=OraOLEDB.Oracle;Data Source=inst1;User Id=scott;Password=tiger"
objRst.Open "Select * from emp where sal < 0", "OraOLEDB.Oracle"
objRst.MoveFirst

Exit Sub
ErrHandler:
MsgBox "Error source:" & Err.Source & ", Description: " & Err.Description


I trust this is clear now.

>>And on two different machines you get a different result for Err.Source. On some it is ADODB.Recordset and on others ADODB.Connection.

Is that correct?<<

No. On one machine Err.Source is ADODB.Recordset. The error is because there are no rows in the recordset and therefore MoveFirst gives error. But, on another machine, Err.Source is the name of the VB project. (Example: If VB project's name is TestClient, then that comes as Err.Source). This means that in one machine, error is generated by ADO and in another by VB itself. But, do not know why.

As I wrote in the previous post, in one machine Err.Source is ADODB.Recordset and in another it is the VB project's name. Err.Description is also different.

The machine that gives Err.Source as ADODB.Recordset gives Err.Description as
"Either BOF or EOF is True, or the current record has been deleted. Requested operation requires a current record."

I am not able to work on the other machine as of now. I do not remember the exact error description in that. (Somebody else is using that machine now.) But I remember that the error description in that machine is method something of some object failed. For example,
"Method MoveFirst of ADODB.Recordset object failed.

To acperkins:-
You are getting 'Provider cannot be found' error. I am not getting that error. But you can try with some other provider also. For example, change provider to "MSDAORA". Still, I get different error source in different machines:- In one it is ADODB.Recordset and in the other it is the VB project's name.

>>But I remember that the error description in that machine is method something of some object failed. <<
That is exactly my point.  They are not the same error message or the code is different.  Which is it?

>>You are getting 'Provider cannot be found' error. I am not getting that error. <<
Of course you are not.  This was just an example how you can get the same error with a different Err.Source.

>>Still, I get different error source in different machines:- <<
Again, re-read my comments and it should make sense.

>>In one it is ADODB.Recordset and in the other it is the VB project's name.<<
Again, it is quite simple if it is an ADO error than sure the Err.Source will an ADODB obeject, if on the other hand it is a VB error such as "method something of some object failed" (take the time to look up VB error 91) than the Err.Source will be a VB project error.

If it was Error 91 than the Error was a VB error and the description was:
Object variable or block with variable not set.

acperkins,
I think what avinash is trying to ask (if I understand correctly), how come the same executable gives a different error source when run from two different machines, which seem to be configured identically MDAC, ADO and VB runtime wise

Dabas

avinash:

To your MsgBox statement inside the ErrHandler, add Err.Number and let us know the numbers that appear on the different systems

Dabas

>>That is exactly my point.  They are not the same error message or the code is different.  Which is it?<<

Code is same.

>>I think what avinash is trying to ask (if I understand correctly), how come the same executable gives a different error source when run from two different machines, which seem to be configured identically MDAC, ADO and VB runtime wise<<

Yes, this is exactly my question.

Now I remember that the error is "Method '~' of object '~' failed" and the error number is 1004 in the machine that gives error source as the VB project's name.

In the other machine error number is 3021.

I understand that if error number is itself different, then error description will be different. Likwise, different error source may give different (sometimes same) error description.

But why should any of these be different on different machines?

This one is similar

http://support.microsoft.com/kb/q269479/

Both seem to indicate that different SP versions of the OS can cause the problem.

Do I remember you posting that both systems are WinXP? Do they both have the same SP?

Dabas

Yes, both have same SP and both are WinXP. Both systems have same versions of MDAC dlls. Both have VB 6. Both have same version of VB runtime dll. But, I have not checked versions of all the dlls of VB in the two machines. There was a time when the sample code that I have pasted worked the same in both machines. The machine that gives 'Method ~ of object ~ failed' is not mine. I do not know what all things were done in that machine in the mean time. Is it possible that installing some other things might have modified some VB dll? Or, some COM dll?

If it was my machine, then I could have done various kinds of experiementation. But the machine is of somebody else and we work in two different countries.

I don't know how else to explain it.  So I am going to have to pass on this one.

Good luck.

Sorry for late response. The owner of the system was busy doing other things. When he got time, I asked him to reinstall VB in his machine. That solved the problem. May be that he had installed some other application, which changed some VB dll. But I cannot tell which application that could be. Anyway, the links posted by you from support.microsoft.com are informative.

avinash_sahay,
Thanks for accepting my answer.

Did you manage to figure it out?

Dabas

oops. posted simultaneously with your answer.

Good luck!

We (i.e. myself and the owner of the machine) live in two different countries. We have never seen each other. We have not even talked on phone. We have only interacted through emails. So, I did not consider it good to tell him to keep trying various options. I wanted to try him what was most likely to solve the problem. Since I had already checked the versions of MDAC dlls in his machine and found them to be the same as on mine, I ruled out the possibility of MDAC version being problem. That is why I asked him to reinstall VB. Anyway, good that this solved the problem.