http://www.able-consulting.com/MDAC/ADO/Connection/OLEDB_Providers.htm#OLEDBProviderForSQLServer

HTH
Mike

--- Mischa Kroon <[EMAIL PROTECTED]> wrote:
> I know ASP.NET solves this by account impersonation. 
> But am unsure how to solve this with ASP. 
> 
> Btw you are doing something stupid. 
> Using .txt for the extension of your include files makes them readable from
> the web since people are able to view these files ( they aren't parsed )
> 
> 
> 
> -----Original Message-----
> From: vkanids [mailto:[EMAIL PROTECTED] 
> Sent: dinsdag 11 mei 2004 22:22
> To: [EMAIL PROTECTED]
> Subject: [AspClassicAnyQuestionIsOk] Connection string issues with SQL
> Server windows authentication
> 
> Hi all,
> 
> I've stumbled upon a problem that I cannot solve, and our local IT 
> group and Server administration group is scratching their heads also.
> 
> I have a classic ASP application (Windows Server 2000, SQL Server 
> 2000, ASP 3.0).
> I'm in the process moving this application for the first time
> ever from the developmental environment to the production 
> environment.  
> The developmental environment is one windows box, combining web 
> server and database server.  The production environment consists of 
> two boxes, one acting as the web server and the other as the database 
> server.  Both have the same versions of server software installed.
> 
> At the same time that I am moving the application, I have been 
> directed to change the SQL Server authentication from "SQL Server
> and Windows" to "Windows only".  I am told that the owner
> of
> the target production network will not allow our application to be 
> hooked-in so long as we are running in mixed-mode.
> 
> My working (mixed mode) connection string is as follows:
> conn.ConnectionString = "Provider=SQLOLEDB.1;Password=;Persist 
> Security Info=True;User ID=CEC;Initial Catalog=CECDB;Data Source=CEC-
> SQL"
> 
> My non-working (windows authentication) connection string is as 
> follows:
> conn.ConnectionString = "Provider=SQLOLEDB.1;Persist Security 
> Info=True;Integrated Security=SSPI;Initial Catalog=CECDB;Data 
> Source=CEC-PROD-SQL"
> 
> The changes are between the connection strings are:
>    1) I removed the "User ID=" & "Password="
> parameters
>    2) I added the "Integrated Security=SSPI" parameter
>    3) The "Data Source" points to the new SQL Server box
> I've also tried adding "Trusted Connection=Yes" &
> "Trusted User=True".
> The underlying database is the same, having been backed up on the 
> developmental system and restored on the target system.  I can look 
> at it just fine in Enterprise Manager, and I can connect to both 
> databases using MS-Excel from another machine on the network and 
> download table contents.
> 
> However, and (finally) here's the problem -
> When I launch my ASP application, the first thing it does after 
> setting up some frames and drawing some graphics is to attempt to 
> access the database to check the "tblPersonnel" to validate
> the user login.  When the ASP code tries to access the database, the 
> following occurs on the main window frame of the application:
> 
> Microsoft OLD DB Provider for SQL Server error '80040e4d'
> Login Failed for user 'NT AUTHORITY\ANONYMOUS LOGON'.
> /includes/connection.txt, Line 4
> 
> Here is the connection.txt file (it contains the same connection 
> string as detailed above - watch for line wrapping - line 4 
> is "Conn.Open"):
> <%
> Set conn = Server.CreateObject("ADODB.Connection")
> conn.ConnectionString = "Provider=SQLOLEDB.1;Persist Security 
> Info=True;Integrated Security=SSPI;Initial Catalog=CECDB;Data 
> Source=CEC-PROD-SQL"
> Conn.Open
> %>
> 
> The SQL Server configurations are identical between development and 
> production so far as I can determine, as are the IIS configurations.
> 
> Is there anyone out there who might provide some enlightenment to me 
> on how to solve this conundrum?  I have Googled this error code and 
> message to death, and am near blind from reading Microsoft Knowledge 
> Base articles, both to no avail.  The only thing that I've been
> able to glean from those resources was to add some logins to the SQL 
> Server of the form "IUSR_<machine name>", but that didn't
> help any either.
> 
> My two suspicions are that
>    1) either I'm doing something completely stupid and am too
> close to the problem to catch it;  or 
>    2) there is some issue about moving from a single-server 
> developmental system to a dual-server production system that I am 
> missing out on and not allowing for.
> But I freely admit that I am completely stumped; I have no idea of 
> where to go from here.
> 
> This seems like such a simple problem, but I've been at it for 
> several days now and cannot get it to go away.  Is there anyone out 
> there who can help?
> 
> Thanks,
> Cary
> 
> 
> 
> 
> 
>  
> Yahoo! Groups Links
> 
> 
> 
>  
> 
> 



        
                
__________________________________
Do you Yahoo!?
Yahoo! Movies - Buy advance tickets for 'Shrek 2'
http://movies.yahoo.com/showtimes/movie?mid=1808405861 


------------------------ Yahoo! Groups Sponsor ---------------------~-->
Yahoo! Domains - Claim yours for only $14.70
http://us.click.yahoo.com/Z1wmxD/DREIAA/yQLSAA/saFolB/TM
---------------------------------------------------------------------~->

 
Yahoo! Groups Links

<*> To visit your group on the web, go to:
     http://groups.yahoo.com/group/AspClassicAnyQuestionIsOk/

<*> To unsubscribe from this group, send an email to:
     [EMAIL PROTECTED]

<*> Your use of Yahoo! Groups is subject to:
     http://docs.yahoo.com/info/terms/
 

Reply via email to