#29224 [Com]: DB Error: extension not found

[jaapjp at zonnet dot nl]

 ID:   29224
 Comment by:   jaapjp at zonnet dot nl
 Reported By:  marcschroeder at hotmail dot com
 Status:   Bogus
 Bug Type: *Configuration Issues
 Operating System: Microsoft Windows XP
 PHP Version:  5.0.1
 New Comment:

Make that eight. I've got the same problem (unable to load dynamic
library 'c:\php\ext\php_mysql.dll' - Kan opgegeven module niet vinden)
under Apache 2.0.50 with PHP 5.0.1. The path given in the error message
is correct


Previous Comments:


[2004-09-12 14:37:03] rene_nadorp at planet dot nl

That's 7 users reporting the same problem: I get the same error message
(unable to load module php_mysql.dll. module not found), although it's
in the right directory (../ext). Loading modules from the same
directory is succesful. Only mysql results in error.



[2004-09-11 01:43:45] php at pattersonweb dot org

I have seen this same error under Apache 1, with PHP 5.0 and Mysql 4...



[2004-08-27 23:27:52] at989 at earthlink dot net

I think this is a IIS problem, not PHP. I had the same thing several
times, and each time it goes away after I tweak something in IIS.
I changed the dll to which the php extension is maped to see if I got a
similar message or not (to see if this was indeed a php or iis problem).
I got module not found message. After I restored the mapping,
everything worked fine :-/
I have no idea why this happened. But i hope this will help someone who
knows more about iis to figure this out.



[2004-08-23 18:31:01] bentrafford at yahoo dot com

Make that six users with the same problem. I've searched the bug
database, the net, newsgroups, and found no resolution to this issue,
other than PHP developers declaring it bogus.

Well, I've got my path updated, and the following set in my php.ini:
extension_dir = .;c:/php/ext/

I'm still getting the same issue as described above. This is either a
bug with PHP or a bug with the documentation.



[2004-08-03 00:58:50] marcschroeder at hotmail dot com

Who set the status to 'Bogus'? Why?

I pretended that the current installation of PHP 5.0.0. does not
install PEAR DB?

5 users claimed that they could reproduce the bug.

The suggested solutions consisted in moving files around on a computer
to places where it might work. The solutions only claim to solve the
problem, but do not claim that there is no problem.

Somebody else suggests that I change the system path.
But I did add the following system variables already:
PHP_PEAR_SYSCONF_DIR=C:\\php
PHP_PEAR_INSTALL_DIR=C:\\php\\pear
PHP_PEAR_DOC_DIR=C:\\php\\pear\\docs
PHP_PEAR_BIN_DIR=C:\\php
PHP_PEAR_DATA_DIR=C:\\php\\pear\\data
PHP_PEAR_PHP_BIN=C:\\php\\php.exe
PHP_PEAR_TEST_DIR=C:\\php\\pear\\tests

Do these environment variables have no effect?

I start to believe that PHP is a tool for hackers only, and that the
need of a controlled installation procedure is not present in the mind
of the PHP community.

This is really sad, as I like PHP a lot.



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/29224

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

#10804 [Com]: No HTTP_POST_VARS

[jaapjp at zonnet dot nl]

 ID:   10804
 Comment by:   jaapjp at zonnet dot nl
 Reported By:  hectorp at buckfoodsvc dot com
 Status:   Bogus
 Bug Type: Other web server
 Operating System: Windows 2000
 PHP Version:  4.0.5
 New Comment:

I'm haveing exactly the same problem here with PHP 5.0.1 under Xitami
v2.5b1 here. Xitami was installed as an NT service. PHP was installed
useing the standard windows installer, useing the default settings. My
system config (from phpinfo()):

System  Windows NT OPMAAK 5.1 build 2600
Build Date  Aug 12 2004 23:30:01
Configure Command   cscript /nologo configure.js --with-gd=shared
--enable-snapshot-build
Server API  CGI/FastCGI
Virtual Directory Support   enabled
Configuration File (php.ini) Path   C:\WINDOWS\php.ini
PHP API 20031224
PHP Extension   20040412
Zend Extension  220040412
Debug Build no
Thread Safety   enabled
IPv6 Supportenabled
Registered PHP Streams  php, file, http, ftp, compress.zlib
Registered Stream Socket Transports tcp, udp


Previous Comments:


[2002-05-24 20:34:22] [EMAIL PROTECTED]

Thank you for taking the time to report a problem with PHP.
Unfortunately your version of PHP is too old -- the problem
might already be fixed. Please download a new PHP
version from http://www.php.net/downloads.php

If you are able to reproduce the bug with one of the latest
versions of PHP, please change the PHP version on this bug report
to the version you tested and change the status back to Open.
Again, thank you for your continued support of PHP.





[2002-01-27 04:14:45] pliszka at bellatlantic dot net

I have the same problem.

PHP 4
IIS 4
Windows NT 4.0 Server



[2001-05-11 04:17:32] hectorp at buckfoodsvc dot com

PHP 4.0.5 and 4.0.4pl1 (tried the latter as a fallback) downloaded as
binaries from your php.net site, running Xitami.  Also tried on a
Windows ME machine and got the same results, which are:

POSTing from a form does not result in the $HTTP_POST_VARS array being
created.  It also doesn't create the global versions of these variables
(with register_globals on or off).  However, it _does_ create
appropriate entries in $HTTP_ENV_VARS['FORM_*'] and
$HTTP_SERVER_VARS['FORM_*'].  Additionally, $HTTP_COOKIE_VARS show up
fine (unrelated, just FYI).

I used this code to emulate (badly) the HTTP_POST_VARS variables,
just to be sure that was really the problem:

if(count($HTTP_POST_VARS)  2) { // test always succeeds
  reset($HTTP_ENV_VARS); // is set, but is 0 size
  while(list($k,$v) = each($HTTP_ENV_VARS)) {
if(!strncmp($k,FORM_,5)) {
  $g = strtolower(substr($k,5));
  $HTTP_POST_VARS[$g] = $v;  // create fake array var
  $$g = $v;  // create fake global var
}
  }
}

I tried several scripts from the internet (Phorum, etc.) and had the
same problem with all, whenever a form POSTed, on both machines using
both versions of PHP.  Even a form with only a simple submit button
fails without the above hack.  This is bizaare.

Here are some typical results from phpinfo() after a POST:

This is from the Environment section:

QUERY_METHOD POST 
REQUEST_METHOD POST 
 ...
FORM_SET Login 
FORM_AUTHKEY   
FORM_AUTHPASS  
FORM_AUTHUSER Myadmin23 
FORM_REFERERURL http://forum.hectorplasmic.com/frontpage.php 

This is from the PHP Variables section:

HTTP_SERVER_VARS[QUERY_METHOD] POST 
HTTP_SERVER_VARS[REQUEST_METHOD] POST 
 ...
HTTP_SERVER_VARS[FORM_SET] Login 
HTTP_SERVER_VARS[FORM_AUTHKEY]  
HTTP_SERVER_VARS[FORM_AUTHPASS]  
HTTP_SERVER_VARS[FORM_AUTHUSER] Myadmin23 
HTTP_SERVER_VARS[FORM_REFERERURL]
http://forum.hectorplasmic.com/frontpage.php 

So is this:

HTTP_ENV_VARS[QUERY_METHOD] POST 
HTTP_ENV_VARS[REQUEST_METHOD] POST 
HTTP_ENV_VARS[GATEWAY_INTERFACE] CGI/1.1 
HTTP_ENV_VARS[SERVER_SECURITY] - 
HTTP_ENV_VARS[SERVER_PROTOCOL] HTTP/1.1 
HTTP_ENV_VARS[SERVER_PORT] 80 
 ...
HTTP_ENV_VARS[SERVER_VERSION] 2.5b1 
HTTP_ENV_VARS[SERVER_SOFTWARE] Xitami 
HTTP_ENV_VARS[FORM_SET] Login 
HTTP_ENV_VARS[FORM_AUTHKEY]  
HTTP_ENV_VARS[FORM_AUTHPASS]  
HTTP_ENV_VARS[FORM_AUTHUSER] Myadmin23 
HTTP_ENV_VARS[FORM_REFERERURL]
http://forum.hectorplasmic.com/frontpage.php 


So is this, but they're my fake variables created by the code above. 
These don't show up without that code -- no HTTP_POST_VARS at all.

HTTP_POST_VARS[set] Login 
HTTP_POST_VARS[authkey]  
HTTP_POST_VARS[authpass]  
HTTP_POST_VARS[authuser] Myadmin23 
HTTP_POST_VARS[refererurl]
http://forum.hectorplasmic.com/frontpage.php 

Here's the form (stripped of HTML formatting crud):

form method=post action=/login.php name=login
 input type=hidden name=refererurl
value=http://forum.hectorplasmic.com/frontpage.php;br
 Username:  input class=inp type=text name=authUser
 Userpass