php.net |  support |  documentation |  report a bug |  advanced search |  search howto |  statistics |  random bug |  login
Bug #21928 Cannot find valid ODBC DSN
Submitted: 2003-01-28 16:57 UTC Modified: 2003-02-13 19:46 UTC
Votes:14
Avg. Score:4.5 ± 0.9
Reproduced:11 of 11 (100.0%)
Same Version:7 (63.6%)
Same OS:9 (81.8%)
From: Matt dot hintze at nana dot com Assigned:
Status: No Feedback Package: ODBC related
PHP Version: 4.3.0 OS: Win2k server
Private report: No CVE-ID: None
Anyone can comment on a bug. Have a simpler test case? Does it work for you on a different platform? Let us know!
Just going to say 'Me too!'? Don't clutter the database with that please !
Your email address:
MUST BE VALID
Solve the problem:
31 + 16 = ?
Subscribe to this entry?

 
 [2003-01-28 16:57 UTC] Matt dot hintze at nana dot com
PHP cannot find a valid ODBC datasource.  Even though the DSN has been verified and connected to with other products like MS access.  The DSN points to a SQL Server database.  To complicate matters, PHP can see a DSN that was previously created on for the same SQL server instance.  But when trying to create any new DSN, PHP cannot see it.  This app was run on my local win2k pro box and worked fine.  When I moved it to my Win2k server, it cannot fins the ODBC DSN.  I see other bug posts that have had the same problem, yet reponses say that it is not a bug.

Line 10 > 
$connect_TI = odbc_connect("ti_readonly","TI_readonly","TI_readonly");

Warning: SQL error: [Microsoft][ODBC Driver Manager] Data source name not found and no default driver specified, SQL state IM002 in SQLConnect in c:\inetpub\wwwroot\survey\survey.php on line 10

Patches

Pull Requests

History

AllCommentsChangesGit/SVN commitsRelated reports
 [2003-01-28 18:17 UTC] pollita@php.net
Is "ti_readonly" a userDSN or a systemDSN?  

Run this EXACT script from the COMMAND LINE on your server and report the output:

<?php
  var_dump(odbc_connect("ti_readonly","TI_readonly","TI_readonly"));
?>
 [2003-01-28 18:47 UTC] Matt dot hintze at nana dot com
This is a system DSN.

Here is the output from the lines you sent me.

Content-type: text/html
X-Powered-By: PHP/4.3.0

resource(1) of type (odbc link)
 [2003-01-28 22:40 UTC] kalowsky@php.net
I don't believe this is a PHP bug itself at all.  First off what version of the MDAC are you using?

Second can you try doing the following:

$dbh = odbc_connect();  // yes I know it will fail
$res = odbc_data_source($dbh, SQL_FETCH_FIRST);

And print out the results of the $res, and call the data_source() a few more times with SQL_FETCH_NEXT instead of SQL_FETCH_FIRST?

Thanks

 [2003-01-29 00:27 UTC] Matt dot hintze at nana dot com
I'll run your test in the morning.  It might be notable that I can run my script from the command line and have no problems connecting to the ODBC DSN.  But when I run it through IIS, it fails.  I ran this same script on my local win2k pro desktop and it works fine.  This is only happening on my win2k server.  I searched the net and see lots of people with this same issue, but cannot find a single one that has a resolution.
 [2003-01-29 00:29 UTC] Matt dot hintze at nana dot com
BTW:  I am running MDAC 2.7 SP1
 [2003-01-29 12:23 UTC] Matt dot hintze at nana dot com
This is what I ran from IIS

<?
$dbh = odbc_connect();  // yes I know it will fail
$res = odbc_data_source($dbh, SQL_FETCH_FIRST);
echo $res;
$res = odbc_data_source($dbh, SQL_FETCH_NEXT);
echo $res;
?>

These are the results.
Warning: Wrong parameter count for odbc_connect() in c:\inetpub\wwwroot\survey\test.php on line 3

Warning: odbc_data_source(): supplied argument is not a valid ODBC-Link resource in c:\inetpub\wwwroot\survey\test.php on line 4

Warning: odbc_data_source(): supplied argument is not a valid ODBC-Link resource in c:\inetpub\wwwroot\survey\test.php on line 6
 [2003-01-29 16:49 UTC] pollita@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)
 [2003-01-29 19:27 UTC] kalowsky@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-30 00:17 UTC] pollita@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-02-13 19:46 UTC] sniper@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-05-13 23:59 UTC] 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).
 [2010-10-08 16:14 UTC] fredjo25 at yahoo dot com
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.
 
PHP Copyright © 2001-2024 The PHP Group
All rights reserved.
Last updated: Tue Dec 03 21:01:29 2024 UTC