Why would the error "No error message available, result code: DB_SEC_E_AUTH_FAILED(0x80040E4D)" begin showing up in MSVS 2010?

e_livesay
e_livesay used Ask the Experts™
on
I am writing regarding an error that has very recently (yesterday) appeared in the development environment of a piece of C# software that has been under development for nearly three years. The code is housed in a Subversion Repository and five developers total (including myself are working on it) using Microsoft Visual Studio 2010 (originally we used MSVS 2008).

The MSVS solution is a collection of 8 projects and a main form (call if frmX) which has a TabControl on it which coincidentally has 8 TabPages on it (i.e., there is not one TabPage per project).  To make the code more managable frmX is broken into a total of 9 files; the main file which has a Designer.cs file and 8 auxillary files, one for each TabPage.

Last night when I opened frmX from the MSVS Solution Explorer by double-clicking it, I received 9 identical error messages which appeared one after the other, all of which say:
No error message available, result code: DB_SEC_E_AUTH_FAILED(0x80040E4D).
I don't know that there are 9 because there are 9 frmX files but it seems related...

After clicking OK on these errors, the form opens in the MSVS Designer.  The code will clean successfully.  The code will build successfully.  The code will run.

Two of us have been chasing this problem today but cannot find any reason for why they are appearing.  Any thoughts on where these are coming from and how we can get rid of them?
Comment
Watch Question

Do more with

Expert Office
EXPERT OFFICE® is a registered trademark of EXPERTS EXCHANGE®
Jesse HouwingScrum Trainer | Microsoft MVP | ALM Ranger | Consultant

Commented:
Googleling the error message brings up errors related to the Connectionstring in your code or in the project file, config file or dataset.

http://osherove.com/blog/2003/4/3/avoiding-db_sec_e_auth_failed-exception-on-connection-string.html

Author

Commented:
Thanks for your reply.

I had seen some references on the web to this problem being related to a connection string issue but didn't see how it pertained to my problem since the errors appear in the development environment, prior to running the program.  However, I began deleting user-controls from main main form (i.e., frmX in my original posting) and the errors began disappearing.  In the constructor for those user controls a DB connection is initialized (i.e., a variable of type OleDBConnection is initialized).  Obviously deleting the user controls is not a long term solution but moving the initialization of the DB connection out of the constructor seems to be a possibility.

I guess that when the Visual Studio Designer shows frmX in the development environment it runs the constructor of the user-controls, tries to make the DB connection at that time and fails.

Deleting four user controls led to eight of the nine errors.  The relationship between the nine errors and the nine frmX files turned out to be coincidental afterall.
Scrum Trainer | Microsoft MVP | ALM Ranger | Consultant
Commented:
You should not initialize a connection or anything that can throw an exeption in a usercontrol constructor. Use the Load Event and if needed make sure you're checking whether or not the control is in design mode (and skip the connection initialization code).

http://msdn.microsoft.com/en-us/library/system.windows.forms.usercontrol.load.aspx
http://msdn.microsoft.com/en-us/library/system.componentmodel.component.designmode.aspx

Author

Commented:
Thanks for your help.  The problem has been fixed.

Eight of the nine errors were dealt with by removing the DB connection code from the constructors of four user controls (UCs) - each UC was giving me two errors apiece.  Intead of moving that code into the Load event of the user-control and using the Design mode flag to determine whether or not the code should be performed, I created a new sub-routine named initialize_UC that is only called when the program is running from frmX (the main form).

The ninth error was due to a DB-related variable being declared in the declaration section of a fifth user-control.  However, this variable was unused and it was simply removed from the code.

Do more with

Expert Office
Submit tech questions to Ask the Experts™ at any time to receive solutions, advice, and new ideas from leading industry professionals.

Start 7-Day Free Trial