Error Message

[Mark]

I developed two COM classes in a single VB.Net (2002) project and used the
"Build Solution" command on the Build menu to compile and register the
classes. The Build process appears to work properly.

The problem occurs when the one of the classes is instantiated in Access
2002 VBA procedure. The error arises on the second of the following VBA code:

Dim myClass as myCOMClass
myClass = new myCOMClass

The following error message occurs:

Run-time error '-2147217843 (80040e4d)':

No Error information available:
DB_SEC_E_AUTH_FAILED(0X80040E4D).

Any ideas of what could cause such an error?

Other characteristics of VB.Net project/COM classes (which may be
contributing to the error message):
Should I have separate projects for each COM class? (I'd like to have them
in one place for organization reasons.)
One of the COM classes uses an Imports System.Data.OLEDB statment at the
beginning of the class.

I don't know what to do at this point. Maybe remove code, recompiling and
building trying to isolate any offending code.

Thanks, Mark

[Dennis]

I certainly know very little of com classes but VB.Net uses integers as 4
bytes whereas some other apps might use integers as 2 bytes. If you are
passing integers from Access, this could be a problem...just a thought.
--
Dennis in Houston
"Mark" wrote:

I developed two COM classes in a single VB.Net (2002) project and used the
"Build Solution" command on the Build menu to compile and register the
classes. The Build process appears to work properly.

The problem occurs when the one of the classes is instantiated in Access
2002 VBA procedure. The error arises on the second of the following VBA code:

Dim myClass as myCOMClass
myClass = new myCOMClass

The following error message occurs:

Run-time error '-2147217843 (80040e4d)':

No Error information available:
DB_SEC_E_AUTH_FAILED(0X80040E4D).

Any ideas of what could cause such an error?

Other characteristics of VB.Net project/COM classes (which may be
contributing to the error message):
Should I have separate projects for each COM class? (I'd like to have them
in one place for organization reasons.)
One of the COM classes uses an Imports System.Data.OLEDB statment at the
beginning of the class.

I don't know what to do at this point. Maybe remove code, recompiling and
building trying to isolate any offending code.

Thanks, Mark

[Mark]

Dennis - Thanks for the thought.

It's definitely some code in the program (duh, stating the obvious)- I'm
still working through it but at least I have hope to lick it.

What was throwing me was that the code was working at some point. But I
made a few changes (what I thought were minor) and it started giving me
trouble. I mistakeningly thought it was a bug with VB.Net, not my program
(ah, the arrogance).

Mark

"Dennis" wrote:

I certainly know very little of com classes but VB.Net uses integers as 4
bytes whereas some other apps might use integers as 2 bytes. If you are
passing integers from Access, this could be a problem...just a thought.
--
Dennis in Houston
"Mark" wrote:

I developed two COM classes in a single VB.Net (2002) project and used the
"Build Solution" command on the Build menu to compile and register the
classes. The Build process appears to work properly.

The problem occurs when the one of the classes is instantiated in Access
2002 VBA procedure. The error arises on the second of the following VBA code:

Dim myClass as myCOMClass
myClass = new myCOMClass

The following error message occurs:

Run-time error '-2147217843 (80040e4d)':

No Error information available:
DB_SEC_E_AUTH_FAILED(0X80040E4D).

Any ideas of what could cause such an error?

Other characteristics of VB.Net project/COM classes (which may be
contributing to the error message):
Should I have separate projects for each COM class? (I'd like to have them
in one place for organization reasons.)
One of the COM classes uses an Imports System.Data.OLEDB statment at the
beginning of the class.

I don't know what to do at this point. Maybe remove code, recompiling and
building trying to isolate any offending code.

Thanks, Mark