It’s always the simplest answer, isn’t it? Earlier in the week, I wrote my first ADO.NET code against a Sybase DB. The code worked perfectly in my test Console applicatio, but bombed out with the following error when I moved it into my web service:
The ‘Sybase ASE OLE DB Provider’ provider is not registered on the local machine. –> No error information available: REGDB_E_CLASSNOTREG(0×80040154).
Whenever code works in a console application but not in a web context, the problem generally has to do with permissions. Specifically, permissions which the ASPNET account doesn’t have, but which your account does have. In this case, that turned out to be a good call.
Seeing the string “REGDB_E_CLASSNOTREG” in the error message I assumed that the problem was a registry key permission issue. I ran RegMon on the workstation I was using, but didn’t see any access denied messages. The next logical thing would have been to use a tool like SysInternal’s other must have tool, FileMon, to see if the problem was actually an ACL on some important file. But I didn’t.
For some reason, I decided that I must have been running into some esoteric issue involving OLEDB provider versions and OS setup. I searched using all of my usual tools, and found tons of articles with the aforementioned error message. Most of the threads ended with users switching from using the built in .NET Framework Data Provider for OLE DB, in favor of the ASE ADO.NET Data Provider from Sybase.
An hour or so later, it finally occured to me that the problem might be file permissions. I started up FileMon, and noticed that the DLL which make up the Sybase OLEDB drivers had been installed on a mapped network drive, rather than locally on the machine. Bingo! The ASPNET account is a local account, and so couldn’t access the necessary libraries. The “REGDB_E_CLASSNOTREG” had been a red herring. So, if you run into this error in one of your ASP.NET applications, check the file permissions!