p2p.wrox.com Forums

p2p.wrox.com Forums (http://p2p.wrox.com/index.php)
-   Classic ASP Databases (http://p2p.wrox.com/forumdisplay.php?f=62)
-   -   Classic ASP: SQLSetConnectAttr Failed (http://p2p.wrox.com/showthread.php?t=87549)

lithgowers May 16th, 2012 03:57 PM

Classic ASP: SQLSetConnectAttr Failed
I am using MySQL and classic ASP to add/edit/update records through a web page. I have a database that was recently switched over to a Server 2008 environment. Since the switch I am having a very strange problem. When updating more than 790 records (used LIMIT to check the tolerance) I receive the error message below:

Microsoft OLE DB Provider for ODBC Drivers error '80004005'
[Microsoft][ODBC Driver Manager] Driver's SQLSetConnectAttr failed
/aRPTS/mlist/add_list_BB.asp, line 8

That line is:
Set ConnSQL = Server.CreateObject("ADODB.Connection")

I have a feeling it is a permission problem, IIS-wise, using root access for the DB itself, or possibly a "buffer" limit but I can't figure it out.

I can read thousands or records just fine in this particular app and in ANOTHER app on the same server with the same connection string (different database name) I can successfully insert/update thousands (40k) of records. It appears to be an isolated issue with this folder/database.

Any suggestions would be appreciated.

Imar May 17th, 2012 11:14 AM

Hi there,

80004005 errors are almost always related to security. For more details:


On Windows Server the account you use is *probably* something like IIS AppPool\NameOfTheAppPool. The part before the slah is fixed, the second part should be the name of the ppol. You can find out if this is indeed the account by looking at the site so see which pool it uses, and then look at the settings of the app pool and see if the identity is set to ApplicationPoolIdentity.



lithgowers May 17th, 2012 12:00 PM

Thanks for the response.

The application pool is just the DefaultAppPool and is the same as other apps within my default website that are working fine. It is indeed set to ApplicationPoolIdentity as well. I went through the link but couldn't follow to well as I am using IIS7. As far as the permissions are concerned I have everything wide open though. Any other suggestions would be appreciated.

Imar May 17th, 2012 12:05 PM


I have everything wide open though
Can you define wide open? Does IIS AppPool\DefaultAppPool have write access to the folder that contains the databse, not to just the database file itself?


lithgowers May 17th, 2012 12:28 PM

The folder is set to full access to Everyone and the other applications in my website using the DefaultAppPool don't have this issue.

Could it possibly come from a corrupt database?

Imar May 17th, 2012 12:38 PM

Are you using a DSN for your connection? And did you recreate that on the new server? Googling for "Driver's SQLSetConnectAttr failed" seems to suggest DSN related issues.



lithgowers May 17th, 2012 12:49 PM

I am not using DSN, I am using an ODBC connection string. I did set up the DSN to see if I could get it to work that way but it still throws the same error. [:confused:]

Imar May 17th, 2012 03:03 PM

In that case, I am almost out of ideas. Stuff you could try:

1. See if the application pool runs in 32 or 64 bit mode. It might work on 32 bits
2. Use an OLEDB connection string.
3. See if Google brings up more results for the exact error message.



lithgowers May 17th, 2012 03:05 PM

Thanks for the input, I'll give those suggestions a shot and post a response if I can get it to work in case other run into such an issue. Thanks again!

lithgowers May 18th, 2012 10:42 AM

Tried all of the suggestions but to no avail. Unfortunately Google is of little to no help, the forums were my last resort. I'll keep the post up to date if I manage to solve it. I think my next step is to recreate the database and test again to see if the DB is corrupt.

lithgowers May 21st, 2012 12:38 PM

Just wanted to update the thread. It seems that the error is coming from the ASP buffer. When passing the form from one routine to the next I was passing a ton of information, which was apparently too much for it, thereby causing it to throw the error. When I removed some of the fields that I was passing it worked fine. I am now working on changing the way the form moves the information and hopefully that will solve the problem permanently.

Imar May 21st, 2012 02:36 PM

Interesting. I think that's the first 80004005 error I see that's not related to security (unless using a large buffer is a permission as well ;-) )

Thanks for the update.



All times are GMT -4. The time now is 10:27 AM.

Powered by vBulletin®
Copyright ©2000 - 2020, Jelsoft Enterprises Ltd.
© 2013 John Wiley & Sons, Inc.