Jump to content

Recommended Posts

This topic seemed to have been put to bed three years ago but I can't get past msql_connect().

 

My system Description:

XP Professional, SP3

Firefox 3.0.7 (Same result with IE6.0)

IIS 5.1

php 5.2.9-Win32.zip into C:\PHP5.

MySQL mysql-essential-5.1.32-win32.msi

 

I can run php and msql separately with no problem but can't connect them.

I wrote a test file to try and exercise mysql (test.php) as follows:

 

<html>

<body>

<h3>Hello World</h3>

<?php

    echo '<br />display_errors = ' . ini_get('display_errors');

    echo '<br />register_globals = ' . ini_get('register_globals');

    echo '<br />post_max_size = ' . ini_get('post_max_size');

    echo '<br />mysql.default_user = '. ini_get('mysql.default_user');

    $dbc = msql_connect('127.0.0.1', "Edward");

    echo("Foo after connect");

?>

</body>

</html>

 

I put the echo() functions in there to show that php was really working. 

Output when run in Firefox browser (http://localhost/SalesForm/test.php):

 

Hello World

 

display_errors = 1

register_globals = 0

post_max_size = 8M

mysql.default_user =

Fatal error: Call to undefined function msql_connect() in

C:\Inetpub\wwwroot\SalesForm\test.php on line 9

 

I had only changed the php.ini file from php.ini-recommended for the

extension_dir and allowed the extension=php_mysql.dll and then copied it

to C:\WINDOWS.

 

I used WinDiff to check the php.ini differences from php.ini-recommended as

follows:

 

extension=php_mysql.dll

; Directory in which the loadable extensions (modules) reside.

extension_dir = "C:\PHP5\ext"

; **You CAN safely turn this off for IIS, in fact, you MUST.**

cgi.force_redirect = 0

 

The following show where the various files are coming from:

C:\>which php.ini

C:\WINDOWS\php.ini

 

C:\>which mysql

C:\Program Files\mysql\MySQL Server 5.1\bin\mysql.exe

 

C:\>which php

C:\PHP5\php.exe

 

C:\>which libmysql.dll

C:\PHP5\libmysql.dll

 

 

One thing I don't understand in the usual instructions for making changes to

php.ini is that I have to do a "restart server."  I've rebooted many times!

I thought php started up every time the .php file was scanned.

 

php was installed by copying binaries from php-5.2.9-Win32.zip into C:\PHP5.

I can start it from the command line and I've attached the output from "php -i" as a text

file.

 

I can start msql from the command line

 

C:\>mysql -u Edward

Welcome to the MySQL monitor.  Commands end with ; or \g.

Your MySQL connection id is 22

Server version: 5.1.32-community MySQL Community Server (GPL)

 

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

...

 

Can somebody recommend anything I can do to fix the problem?

 

 

[attachment deleted by admin]

When I invoke "phpinfo();" the "Loaded Configuration File" is listed as

"(none)" and the Configuration File (php.ini) Path is "C:\WINDOWS".

 

There is only one php.ini file in the system and that's in C:\PHP5.

 

So I moved the php.ini file from C:\PHP5 to C:\WINDOWS and ran the phpinfo();

again.  The loaded config file was still listed as (none).

 

Next I had a thought that "restart the server" meant restart IIS so I did this.

Now phpinfo(); lists the config file path as C:\WINDOWS and the loaded

config file as C:\WINDOWS\php.ini.

 

But running my test.php file doesn't work and in fact I've lost the error

message that I was getting before.  The produced html code is:

 

<html>

<body>

<h3>Hello World</h3>

<br />display_errors = <br />register_globals = <br />post_max_size = 8M<br />mysql.default_user =

 

so nothing has happened (no error message) once php started into:

$dbc = msql_connect('127.0.0.1', "Edward");

 

To test that this is real, I moved php.ini back to the C:\PHP5 folder and

restarted IIS.  The phpinfo() now lists the config file as "(none)".  But

running my test.php file gives me the error message I had seen previously at

the end:

 

...

Fatal error: Call to undefined function msql_connect() in C:\Inetpub\wwwroot\SalesForm\test.php on line 9

 

So when it doesn't read php.ini I get a message, when it does read the php.ini

it must go into mysql_connect(...) and never return!

 

I'm using IIS since I've used it before with Visual Studio and a C# app

together with MS SQLServer.  My preference is to stay with IIS so that

I wouldn't have to install any extra things on my machine.

When your system is actually using the php.ini, display_errors is being turned off, so you don't see any fatal runtime errors.

 

Make sure that display_errors is set to ON and error_reporting is set to E_ALL in your php.ini

I added error_reporting(...) line to the test.php script so that it looks like:

 

<html>

<body>

<h3>Hello World</h3>

<?php

    error_reporting(E_ALL);

    echo '<br />Post_max_size = ' . ini_get('post_max_size');

    $dbc = msql_connect('127.0.0.1', "Edward");

    echo("<br />Continue after connect");

?>

</body>

</html>

 

When I run this I just see the first "echo" - no errors reported.  It dies inside the msql_continue(...).  Is this where I put the error_reporting(E_ALL) line?

 

Sorry.  That was dumb not to get the function correct.

 

I would have expected a message however!  When I change to the correct function (and take out an "echo"):

 

<html>

<body>

<h3>Hello World</h3>

<?php

    error_reporting(E_ALL);

    echo '<br />E_ALL='.E_ALL;

    $dbc = mysql_connect('127.0.0.1', "Edward");

    echo("<br />Continue after connect");

?>

</body>

</html>

 

I get the html code:

 

<html>

<body>

<h3>Hello World</h3>

<br />E_ALL=6143

 

At least I can confirm that the E_ALL is seen and has a value.  But no error messages.

 

When your system is actually using the php.ini, display_errors is being turned off, so you don't see any fatal runtime errors.

 

Make sure that display_errors is set to ON and error_reporting is set to E_ALL in your php.ini

It seems I don't really know where the error message (if any) goes.  I tried the:

 

    echo '<br />Test3: E_ALL='.E_ALL;

    if (!$dbc = mysql_connect('127.0.0.1', "Edward")) {

      die("Could not connect: ".mysql_error());

    }

 

but I don't see any more text in the html output file.  I changed an "echo" so that I could tell that the page really was being re-executed, not being regenerated from a cache.

 

If I set the "display_errors" to on, I don't understand where they will go.  It looks like I use use "Off", "stderr", "On" or "stdout".  Surely the line above in the test.php file for "error_reporting(E_ALL)" will turn the display_errror flag on.

 

When I look in the php.ini file, "error_reporting" is set to E_ALL so I shouldn't have to call the error_reporting(E_ALL) function.  In the php.ini-dist file, E_ALL is modified by ~E_NOTICE but the display_errors is set to "on".  I'm using the php.ini-recommended.

 

Is there a function that I can call from the test.php file to change the "display_errors" flag?

 

Still doesn't tell me where any errors will go.  Is the html code generated equivalent to "stdout"?

Another piece of info.  I changed the display_errors in the php.ini file to "On", restarted IIS and now I get an error message:

 

<html>

<body>

<h3>Hello World</h3>

<br />Test4: E_ALL=6143<br />

<b>Fatal error</b>:  Call to undefined function mysql_connect() in <b>C:\Inetpub\wwwroot\SalesForm\test.php</b> on line <b>7</b><br />

 

 

At least I'm seeing something.

I think I fixed the problem.  I moved libmysql.dll to C:\WINDOWS then the key thing appeared to be that I restarted IIS.  The magic that was going on wasn't apparent but I thought I'd make an experiment.  Move the libmysql.dll back to C:\PHP5 and the mysqli_connect(...) function is still found.  A "which" in a command window confirms that libmysql.dll is back in C:\PHP5.

 

Now I restart IIS.  After the restart, mysql_connect(...) can't be found.

 

So I move libmsql.dll back to C:\WINDOWS, restart IIS and my script works again.  I can only assume that IIS reads php.ini when it's restarted and if libmysql.dll is not in the WINDOWS folder, doesn't look any further for it when the extension=libmysql.dll line is processed.

 

When the restart is over, the actual load of the libmysql.dll must come from the PATH environment.

 

I'm not happy with IIS.

This thread is more than a year old. Please don't revive it unless you have something important to add.

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Restore formatting

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.