Edit report at http://bugs.php.net/bug.php?id=21928&edit=1

 ID:                 21928
 Comment by:         fredjo25 at yahoo dot com
 Reported by:        Matt dot hintze at nana dot com
 Summary:            Cannot find valid ODBC DSN
 Status:             No Feedback
 Type:               Bug
 Package:            ODBC related
 Operating System:   Win2k server
 PHP Version:        4.3.0
 Block user comment: N

 New Comment:

I have the exact same problem.



Running: MS Server 2008 R2 

         SQL Server 2008  

         IIS7

         PHP 5.3.3

I set up a system DSN using the SQL Server driver, TCP\IP dynamic port.

When I run the SQL Server Data Source Test, I get the following result:

Microsoft SQL Server ODBC Driver Version 06.00.6002

...

...

Test Completed successfully!



When I check my php-errors.log  I find: IM002 when attempting an
odbc_connect.

Warning: SQL error: [Microsoft][ODBC Driver Manager] Data source name
not found and no default driver specified...



This script works on another server without any problems.  I doubt this
is a php  issue, but would be interested in any MS centric solutiions.


Previous Comments:
------------------------------------------------------------------------
[2003-05-13 23:59:14] grumpy_old_sod at hotmail dot com

I have exactly the same result:

 IM002 when attempting an odbc_connect.



And in this case the environment is my desktop:

 Win2k with PHP (4.3.1) running as CGI on IIS.



Odbc dsns are:

 Access2k and mssql



Other apps can use the same dsns (such as Borland SQL Explorer)



The ODBC SQL trace shows no difference between 'SQLConnectW' issued by
php and other apps - only that odbc returns the failure message. Odd.



(I'm posting this in case it has been assumed that the problem has
'disappeared', 'cos I don't think it has).

------------------------------------------------------------------------
[2003-02-13 19:46:20] sni...@php.net

No feedback was provided. The bug is being suspended because
we assume that you are no longer experiencing the problem.
If this is not the case and you are able to provide the
information that was requested earlier, please do so and
change the status of the bug back to "Open". Thank you.



------------------------------------------------------------------------
[2003-01-30 00:17:10] poll...@php.net

Matt,



  Please accept my apologies for not seeing that kalowsky was the one to
tell you to do that.  My bad. My bad. My bad.  Now, try a little less
hostility.  I didn't mean to imply you were an idiot, I meant to say I
have no idea who you are, and checking the simple things is the best
place to start.  The lack of ability to reproduce this bug under
identical conditions makes configuration errors the prime suspect. 
That's all, just playing by the numbers.



Can you provide a list of all installed ODBC drivers?  Have you ever
installed the MyODBC Mysql driver?  Have you ever installed the Sybase
System 11 driver?

------------------------------------------------------------------------
[2003-01-29 19:27:40] kalow...@php.net

Pollita yes it was me that suggested he try it.  The odbc_data_source
technically doesn't require a valid connection at all, but rather a
valid environment to be setup, which is done in the odbc_*connect()
functions.  I was hoping that it would be still valid, but I guess the
Zend system denied it (despite the env not being free'd yet).  The hope
was to get the environment to share it's internals with us all!  Yum
yum!



I'd be interesting in knowing what the solution is/was to work around
this so that I might try to fix it in the ODBC module itself. 
Unfortunately all my attempts to reproduce this have come for naught,
but I also don't have SQLServer so that may be part of the problem. 

------------------------------------------------------------------------
[2003-01-29 16:49:34] poll...@php.net

Um.... you issue an odbc_connect() call that you know will fail, then
try to pass the result (which is === FALSE by the way) to commands which
expect a valid resource and you're somehow SURPRISED by the results you
got?



Ignoring that walking contradiction for the moment....



The fact that it's happening on IIS only (and not command line) suggests
one of three posssible explanations:



(A) It's a User DSN created by your user account (hence visible to you
on the command line but not to the webserver who is running as
IUSER_GUEST or whatever) (yes I know you said it was system, but please,
check again as this is the most likely answer)  Just for giggles, try
logging in as another user (non-administrator though) and trying that
sample script I provided earlier on the command line.



(B) There are one or more files (odbc.dlls) which are
unreadable/unexecutable by the IIS user (not terribly common, but at
least possible -- are you in the administrator group?)



(C) You're connecting to an ODBC datasource which requires built in NT
authentication (such as MSSQL) and you have no IUSR_GUEST account on the
SQL server which is somehow throwing an incorrect error message. 
(highly bloody unlikely)

------------------------------------------------------------------------


The remainder of the comments for this report are too long. To view
the rest of the comments, please view the bug report online at

    http://bugs.php.net/bug.php?id=21928


-- 
Edit this bug report at http://bugs.php.net/bug.php?id=21928&edit=1

Reply via email to