Riddle me this error ADODB.Recordset (0x800A0E7A)

[Drew]

This is a weird error, it seems if we reboot the web server, which is also
the SQL server, I get this error,

ADODB.Recordset (0x800A0E7A)
Provider cannot be found. It may not be properly installed.
/swvtc/CliDrAppts/detailDrAppts.asp, line 31

Now line 31 of my asp page is the connection string, so there is nothing
that I can do to get my apps working again.

BUT! (it gets weird here)

If I get the network admin to navigate to this page, it shows it for them
and then after that it works like a charm. Any ideas what could be going
on?

Thanks,
Drew

 

[Ray Costanzo [MVP]]

Can we see line 31?

Ray at work

 

[Drew]

rsCliDrAppt.ActiveConnection = MM_CliDrAppts_STRING

and MM_CliDrAppts_STRING looks like this,

Dim MM_CliDrAppts_STRING
MM_CliDrAppts_STRING = "Provider=SQLOLEDB.1;Trusted_Connection=Yes;Data
Source=swvtc06;Initial Catalog=CliDrAppts;"

It seems like it may be a permissions problem and it has only been doing
this since we upgraded our Primary DC from NT to 2000 (notice I say upgrade,
not a clean install).

Thanks,
Drew

 

[Ray Costanzo [MVP]]

You're using a trusted connection, meaning it's going to pass the
credentials that the page is running under. Is that your intent? ASP apps
typically use a SQL login. So, if you are not authorized to that database
and your site authenticates you and connects as you, you will be denied
access. It makes sense that an admin wouldn't.

Ray at work

 

[Drew]

We are using Windows Integrated Auth. because this on an Intranet. I
thought the same thing, but it doesn't let anyone who doesn't have
permissions in.

Thanks,
Drew

 

[Ray Costanzo [MVP]]

Authenticating your users is fine, but when you're doing that, yes, it will
not let anyone in who doesn't have permissions, well, since, that's what
permissions are used for.

Are you saying that people who ARE authorized also cannot connect?

Does SQL Server need to know who is accessing your intranet? I use
integrated authentication all over my intranet, but I've yet to have the
need to pass that person's credentials for SQL login purposes.

Ray at work

 

[Ray Costanzo [MVP]]

I think it's also important to point out that if you ever separate SQL and
IIS onto two different servers, I believe that your authentication to the
SQL Server will always fail. I'm not familiar with all of the technical
details of how kerberos tickets are created and all that, but I do know that
you cannot "daisychain" authentication from the browser to the IIS server to
a third resource when using integrated authentication. I believe that you
need to use basic authentication then so that a kerberos ticket is created,
which would then be sent along to the third hop.

Ray at work

 

[Drew]

All of my connections use the trusted connection. I'm not even sure why,
but I know that when the server is rebooted, no one can use any of the apps
on the intranet. The intranet itself is fine, but when a users goes to an
app, like Fiscal, to add or change an Employee, this page shows the no
provider error. This happens until an admin navigates to one of the apps,
and then after that everything works fine.

Maybe I do need to change the connection strings. For instance, what do
your connection strings look like?

Thanks,
Drew

 

[Jeff Dillon]

Don't use a trusted connection from a web app. It also defeats connection
pooling

Jeff