ID: 21928
Updated by: [EMAIL PROTECTED]
Reported By: [EMAIL PROTECTED]
Status: Feedback
Bug Type: ODBC related
Operating System: Win2k server
PHP Version: 4.3.0
New Comment:
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?
Previous Comments:
------------------------------------------------------------------------
[2003-01-29 19:27:40] [EMAIL PROTECTED]
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 17:11:22] [EMAIL PROTECTED]
One smart comment deserves another.
I figured out the bug, and I can reproduce, and I know how to get
around it, and the bug is in PHP.
1. The code string "$dbh = odbc_connect(); // yes I know it will
fail" was given to me to run by [EMAIL PROTECTED] Look down in the
post and you will see this. I only tried to follow his directions. So
keep your cracks to yourself until you read the whole post.
2. It is a SYSTEM DSN. I have created a MILLION DSNs in my lifetime,
and it is a SYSTEM DSN. I even tried it as a user DSN and it wouldn't
work. SYSTEM SYSTEM SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM
SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM
SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM
SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM SYSTEMSYSTEM SYSTEM
SYSTEMSYSTEM SYSTEM SYSTEM
3. Again, if you had read the entire post, you would have seen that
this DSN points to a MS SQL server database.
4. I see where many others have had this same issue. The Bug support
group continues to deny it as a bug. I wrote as many as I could and
asked if they had found a resolution. Everyone that wrote back said
they had not, and had given up. If they write me, I will walk them
through the work-around.
5. If you had not been such a smart $%&@, and I might have helped
everyone out by posting the details here on the real problem.
6. Am I stressed out? Maybe..... I spent the last 2 days having
everybody keep telling me that I configured a USER DSN when I did not
and having me run test scripts that would obviously fail.
7. SYSTEM DSN SYSTEM DSN SYSTEM DSN
------------------------------------------------------------------------
[2003-01-29 16:49:34] [EMAIL PROTECTED]
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 12:23:53] [EMAIL PROTECTED]
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 07:19:09] [EMAIL PROTECTED]
kept as feedback until testing done...
------------------------------------------------------------------------
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/21928
--
Edit this bug report at http://bugs.php.net/?id=21928&edit=1
