Error 80040e4d

Thanks, this is good, but I think part of my problem is that I don't know how I should be setting this up.  There are so many options, but I'm not sure which one is the one I should use.  

Make sure to attribute to your ASP account a privilege to access the DB server.  For instance, create an AD domain account for your ASP service to run on and then create a login in SQL that points to that domain account.  If your ASP service runs on a local machine account then make sure that account has sufficient privileges to access the db server...In your case 'JUMBO\IUSR_JUMBO' seems not to be referenced in the logins accepted by SQL Server...Hope this helps...

How do I "create an AD domain account?"

First you need to double check if you have some domain..AD stands for Active Directory...You may want to ask your system administrator to create one for you...

I am the system administrator!  This is all running on a single machine.  My goal is to get this all working between SQL and Flash, if I do it locally then I have to figure it'll work in the upload.

Bumping points, figuring this is getting harder...

Anyone?

Try posting a 20 point LINKING Q in the appropriate Windows TA.  This seems to now be a Windows Q, we have solved the SQL Server bit.

RE: "We have solved the SQL Server bit," with all due respect, I don't think that's been done at all!  You pointed me to a 3rd party site without any indication of which string would be useful or any answers regarding the remainder of the question.  

If I need to be more specific about anything, I surely will.

You might want to take a look at http://www.macromedia.com/cfusion/knowledgebase/index.cfm?id=tn_19064

To quote from the page:
"These errors are generated if SQL Server does not accept the logon account and/or password being submitted. One possible reason could be that a corresponding SQL Server account has not been setup for the Windows NT account used to access the database. An example of an account used to access the SQL Server database could be the IUSR_computername account used by Internet Information Services (IIS) for anonymous access to ASP pages."

In that respect, one of the connection strings listed at the site noted by flavo should work. I haven't done one in a long time, but the one your using should be pretty close.

His suggestion of posting a pointer question in the Windows Server 2003 or IIS topic areas is a good one too. I'd also think about creating one in ASP as well.

Regards,

ep

>I am the system administrator!  This is all running on a single machine.  My goal is to get this all working between SQL and Flash, if I do it locally then I have to figure it'll work in the upload.

If this is going live on the Internet, you will definately want to separate things and if you go with a host, you will be separated and have a SQL login, not an integrated windows login. The ISP wouldn't run the risk of putting the SQL server on a IIS machine, not let you web app run in a domain account.

Okay, just to make a liar out of myself, I was able to assign the local machine account to a local SQL server on one of my development servers.

In enterprise manager running from the server I was able to browse and select the local IIS user.

Which let me do this: "Provider=SQLOLEDB;Server=serverName;Database=examples;Integrated Security=SSPI;"

Also simple, and no domain account.

http://www.rodsdot.com/ee/IUSR_on_local_SQL_server.asp

just to clarify why you're having the problem,
this part of the connection string you are using: Integrated Security=SSPI
says to the web server "use the credentials of the currently logged on user".
You DON'T need to specify a userid and password in the connection string for this connection type.

At the moment, what is being passed across is the IUSR account for that server, this is the anonymous account.
This means, that you have Anonymous authentication turned on for this site in IIS.
To get this connection going, you need to do one of two things,
1, grant the iusr account access to your database.
or
2. go into your IIS properties, turn OFF anonymous authentication and turn on Integrated Windows NT Authentication in the Security tab.

For an internet based system, where the database is most commonly located on a separate system, you need to use BASIC authentication, not integrated.  Windows can't double-hop integrated authentication.  The downsides of basic authentication are that it transfers the credentials in cleartext and it requires the user to enter their logon id and password once per session.

If you don't want to go down this path, get rid of the Integrated Security=SSPI section of your connection string, setup a sql userid and password and pass that along in the connection string.

hope this clarifies.

Now THAT'S an answer, thank you very much.  I'll try all of this out and get back.

Just to clarify, this will not all be on the same machine when it's launched, it's just on the same machine now, for development.

...and said machine is not connected to the Internet, just running IIS locally.  

"... ...and said machine is not connected to the Internet, just running IIS locally..."

That MIGHT matter. Just remember that when you set up the DSN for your database (when you move to production), it wants to be a system DSN, not a user one. I've run into situations where a db is set up using a user DSN and everything works fine, but when the stuff is moved to production, it produces the error (or a similar one) you're getting -- which is why it's a good idea to get in the habit of using nothing but system DSNs.

ep

Don't use a DSN.  It is slower.

I'm with rdivilbiss on that one - bypass the DSN completely, if nothing else it just gives you another point of failure that isn't necessary anyway.

The differences between local and remote access are basically that the site becomes much less forgiving about authentication when it's on separate machines.  Wouldn't hurt to setup a mini network (i.e. one other computer) and try hitting your site just so you have an idea how it's going to respond in a server-client scenario though.  Any problems with the way authentication is setup will show straight away.  Tools like Virtual PC or Virtual Server are great for cheap testing on a single machine.

Don't forget that your IIS logs are your friend :)  Turn on logging for your site, including userid logging so you can see what's coming through with problematic requests.  Default location for these will be c:\windows\system32\logfiles\w3svc* directory.
200 is success, 500 is bad and will usually show ADO errors with the status code, 401 is an auth issue, 404 is a missing page.  

Let us know how you go.

<disclaimer>

Note that I didn't suggest using a DSN... just that if you are going to use one, make sure you set it up correctly.

</disclaimer>

:)

Sure, sure ...

Raydot,

Any update?

ep

Aw...I've just been so busy, and the client has put the project on hold for a week or two, but I haven't forgotten.  I'll be getting back...

IUSR?????   DSN?   You guys must be crazy.  

In a production environment, you should NEVER allow IUSR access to SQL Server.  This is the whole reason for using a login and password.  DSN's are archaic, and slow.  They also create more overhead on the server.

Raydot had the right idea to begin with, I don't see why anyone would chastise him for his current topology.

I develop against a local SQL Server as well.  I also ensure that my connection string is dynamic, so that no matter where my file is, it will execute the correct connection string.  If you want to use only one connection string, it's trivial to just create the same SQL login on the development server, so that once files are moved over, you shouldn't see a difference.  I could go into lengthy detail on all the possible solutions, but with all the solutions already posted, there is no reason confusing someone, who basically almost had it right the first time

For the record I don't feel chastised.

"Ensure my connection string is dynamic..." do tell?

Use something like this:

Dim oConn, ConnString
Dim serverIP as string = request.serverVariables("LOCAL_ADDR")
If serverIP = "Your Dev Machine IP address" Then
ConnString = "Local SQL Connection String"
Else
If serverIP = "Your Host IP" Then
ConnString = "Your Host IP ConnectionString"
End If

set oCconn = CreateObject("ADODB.Connection")
oConn.open ConnString

Oh, right, yes...gotcha.

Well I'm probably going to get back to all of this in the next day or two...so...

nihannet,
While you may have valid comments yourself, I think perhaps you should read through the entire thread before criticising comments made by others.
Speaking for my own comment, I was explaining why, at the present time, the IUSR account (anonymous account) is the one that is being passed instead of integrated credentials.  
I wasn't saying it SHOULD be used, I was saying it WAS being used and what exactly it was in the IIS configuration that was causing this to happen and how to correct it.

Can't we all just get along?  I haven't forgotten you guys, back soon...

Thanks alimu.  Sorry I didn't read your post thoroughly enough.  You're right about why it was causing the problem.   I read many posts on this site, and sometimes, people just get caught in the crossfire.  I've seen some fairly bad advice posted on this site by some people.  Usually it's all about "points" which personally....I have no clue as to what they're for, and could really care less.  It's the content that matters, and as long as you steer someone in the right direction, you're ok in my book.

I only half looked at this stuff before...Rod, you're the man for posting those screen shots!  I'm going through all of this now, will get back in a minute...

OK rdivilbiss, I went with what you wrote because it has such pretty pictures.  When it comes to:

connStr = "Provider=SQLOLEDB;Server=server;Database=table;Integrated Security=SSPI;"

What should I enter for "server?"  The SQL server?  What's that called, to IIS? "local"?

As for the "other" subject...I've been a member of this site for 9 years, and this very type of misunderstanding has been more or less my constant complaint since I joined.  (You'll notice my taking issue along these same lines somewhat earlier in this very thread!)  It's tough, people have only so much time, and on the Internet are only so motivated to care.  I don't mean any of you specifically, it's just an interesting problem in developing an online community.

What to do, what to do...

localhost, is it localhost?  That seems to be working but I get this error running the SQL query rdivilbiss gave me.  The page takes 10 seconds to load and then:

Response object error 'ASP 0251 : 80004005;

Response Buffer Limit Exceeded

/test_adob.asp, line 0

Execution of the ASP page caused the Response Buffer to exceed its configured limit.

There are maybe 10 items in the table.  

I guess I don't know if it's working or not!

Raydot,

Server=server means the name of the SQL server. Assuming it's located within the same network that is hosting your IIS server, it will probably be a single word. Also, instead of Database=table, it should probably be database=database_name. So your connection string would look like:

connStr = "Provider=SQLOLEDB;Server=server_name;Database=database=database_name;Integrated Security=SSPI;"

See http://www.experts-exchange.com/Web/Web_Languages/ASP/Q_21238783.html for more details.

The Response Buffer Limit Exceeded error usually refers to the file size; there's a configuration item in ISS that lets you change it.

http://www.experts-exchange.com/Web/Web_Languages/ASP/Q_21682822.html has a fix -- but you might want to ask this part in the ASP TA.

ep

Thanks Ericpete. Maybe I haven't been clear enough.  I basically used this script, provided above.  The marked areas are the ones that don't seem to be executing.  I started without that part, and then just added them in at the end to see if I could test that I was properly connected, and that didn't work.

Dim conn, rs, query, connectionString
connectionString = "Provider=SQLOLEDB;Server=serverName;Database=databaseName;User
Set conn = Server.CreateObject("ADODB.Connection")
conn.Open connectionString
query = "SELECT * FROM someTable;"
Set rs = conn.Execute(query)

'THIS DOES NOT WORK FROM HERE***
if NOT (rs.BOF AND rs.EOF) then
     while NOT (rs.eof)
              response.write rs(0) & "<br>"
        wend
end if
'TO HERE ***

rs.close
set rs=nothing
conn.close
Set conn=nothing

There are literally 11 lines in the tables, 6 items per line, so I can't beleive that's outside of MSSQL's operational limit.

No, but if the code is creating a loop, it never reaches the EOF, so it keeps repeating the same info so it THINKS it's a big file. But I'm not an ASP Expert, so I can't really tell if that's what's going on.

    while NOT (rs.eof)
              response.write rs(0) & "<br>"
              rs.movenext '// You aren't moving records, so naturally, it's never going to get to the end
        wend

Dave

'THIS DOES NOT WORK FROM HERE***
if NOT (rs.BOF AND rs.EOF) then
     while NOT (rs.eof)
              response.write rs(0) & "<br>"
        wend
end if
'TO HERE ***

We are missing rs.movenext

if NOT (rs.BOF AND rs.EOF) then
     while NOT (rs.eof)
              response.write rs(0) & "<br>"
              rs.movenext
     wend
end if

Thanks flavo.

See? I knew you guys would come through... *grin*

You were close:

"No, ***but if the code is creating a loop, it never reaches the EOF***"

Wow, has it been that long?  Well I haven't forgotten, I'll be back in a few...

The client has picked this job back up, I'll be testing and closing this question in the next few days.  Thanks again, and sorry for the slog.

Realizing that it's Memorial Day Weekend... where are we on this?

Can't go on vacation without hearing back from me?  ;-)  

Well, I'm gonna have to assume y'all are right.  Thanks for your time.  

Oops, meant to split the points...not sure what happened!  Anyway, thanks to all.