mysql_connect statement not connecting to database

mcg...@gmail.com

unread,

Jan 15, 2015, 11:21:20 AM1/15/15

to

I am attempting to try and connect to my mysql database. I am using apache webserver. When I run a php script through localhost through my browser the script works well. When I run my mysql_connect.php then all I get is a blank page. nothing happens. I placed an echo statement at the end to verify that it connected. The echo statement doesn't appear when I refresh the page.

<?php //# Script 7.2 - mysql_connect.php

// This file contains the database access information.
// This file also establishes a connection to MySQL and selects the database.

// Set the database access information as constants.
DEFINE ('DB_USER', 'root');
DEFINE ('DB_PASSWORD', 'pass@word1');
DEFINE ('DB_HOST', 'localhost:3306');
DEFINE ('DB_NAME', 'reg');

// Make the connnection.
$dbc = @mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD) OR die ('Could not connect to MySQL: ' . mysql_error() );

// Select the database.
@mysqli_select_db(DB_NAME) OR die ('Could not select the database: ' . mysql_error() );

echo 'hello';
?>

Matthew Carter

unread,

Jan 15, 2015, 11:49:24 AM1/15/15

to

The '@' suppresses error output, try removing and see what you get.

Does the command line work with those credentials for connecting?

mysql -h localhost:3306 -u root -p'pass@word1'

If that does connect from the CLI, when you do a SHOW TABLES do you see
'reg' listed?

Could be a permissions error with your mysql user or incorrect info.

--
Matthew Carter (m...@ahungry.com)
http://ahungry.com

Thomas 'PointedEars' Lahn

unread,

Jan 15, 2015, 12:01:59 PM1/15/15

to

mcg...@gmail.com wrote:

> […] I am using apache webserver. When I run a php script through

> localhost through my browser the script works well. When I run my
> mysql_connect.php then all I get is a blank page. nothing happens. I
> placed an echo statement at the end to verify that it connected.
> The echo statement doesn't appear when I refresh the page.

The “echo” statement is not supposed to appear. Perhaps you mean that the
output it is supposed to generate does not appear.

[code reformatted to 80 columns]

> <?php //# Script 7.2 - mysql_connect.php
>
> // This file contains the database access information.
> // This file also establishes a connection to MySQL and selects the

> // database.

>
> // Set the database access information as constants.
> DEFINE ('DB_USER', 'root');

^^^^^^

> DEFINE ('DB_PASSWORD', 'pass@word1');
> DEFINE ('DB_HOST', 'localhost:3306');
> DEFINE ('DB_NAME', 'reg');
>
> // Make the connnection.
> $dbc = @mysqli_connect(DB_HOST, DB_USER, DB_PASSWORD) OR

^^

> die ('Could not connect to MySQL: ' . mysql_error() );
>
> // Select the database.
> @mysqli_select_db(DB_NAME) OR die ('Could not select the database: ' .

^^
> mysql_error() );

It is not a good idea to write the identifiers of functions or operators in
all-uppercase. This style should be reserved for constants.

It is also not a good idea to let the opening parenthesis of a function call
be preceded by whitespace. This style should be reserved for control
statements like “if”.

> echo 'hello';
> ?>

You can and should omit the “?>” except when you want to leave PHP parsing
mode to output something (usually in templates only).

Debugging is easier if you do not suppress the messages that code generates.
So, for now, you should remove the “@”s, and run

ini_set('display_errors', true);
error_reporting(E_ALL | E_STRICT);

before all other statements. This should be the default for your local
(development) server, though; edit php.ini if necessary (all recommended
development values are in the comments of a default distribution).

If that still does not help, make sure that the “mysqli” PHP module is
loaded. You can use phpinfo() for that.

Because a Parse Error or a Fatal Error is required for execution not to
reach the “echo” statement. This could be either a syntax error or you
could have attempted to call a function that was not defined, respectively.
I can see no obvious syntax error in the posted code (although your code
lines are too long to be easily readable; consider wrapping at column 80 at
the latest, at least for Usenet) which leaves only the second possibility.

--
PointedEars
Zend Certified PHP Engineer
Twitter: @PointedEars2
Please do not cc me. / Bitte keine Kopien per E-Mail.

Matthew Carter

unread,

Jan 15, 2015, 2:43:49 PM1/15/15

to

GNU style indentation does require a space before the parenthesis (even
for a function call), although I'd imagine there are few GNU based
PHP projects.

Looking at how its completely inconsistent though, I don't think this
was GNU style indentation (my personal favorite actually).

richard

unread,

Jan 16, 2015, 12:13:33 AM1/16/15

to

$mysqli = new mysqli("localhost", "user", "pass", "DBname");
In the connect string you forgot to include DBname.

Denis McMahon

unread,

Jan 16, 2015, 5:04:24 AM1/16/15

to

On Fri, 16 Jan 2015 00:10:52 -0500, richard wrote:

> $mysqli = new mysqli("localhost", "user", "pass", "DBname");
> In the connect string you forgot to include DBname.

richard bullshit strikes again!

The DBname parameter to mysqli_connect is optional.

How many times do we have to tell you not to answer questions because all
you ever do is expose your absolute ignorance of the subject matter.

--
Denis McMahon, denismf...@gmail.com

Thomas 'PointedEars' Lahn

unread,

Jan 17, 2015, 9:49:13 AM1/17/15

to

Matthew Carter wrote:

> Thomas 'PointedEars' Lahn <Point...@web.de> writes:
>> It is also not a good idea to let the opening parenthesis of a function
>> call be preceded by whitespace. This style should be reserved for
>> control statements like “if”.

>> […]

>
> GNU style indentation does require a space before the parenthesis (even
> for a function call), although I'd imagine there are few GNU based
> PHP projects.

My experience (15 years with PHP now) and recent research indicates that
GNU Style is unheard of in the greater PHP developer community.

PHP coding styles include, in no particular order, and not exhaustive:

- PEAR and PEAR2 Coding Standards
<http://pear.php.net/manual/en/coding-standards.php>

- PHP Standard Recommendations PSR-1, PSR-2, and PSR-4 (deprecates PSR-0)
<https://github.com/php-fig/fig-standards/tree/master/accepted>

- Symfony Coding Standards (“follows the standards defined in the PSR-0,
PSR-1 and PSR-2 documents”)
<http://symfony.com/doc/current/contributing/code/standards.html>

- Drupal Coding Standards (“loosely based on the PEAR Coding Standards”)
<https://www.drupal.org/coding-standards>

- WordPress PHP Coding Standards (“similar to Pear standards in many ways,
but differ in some key respects”)
<https://make.wordpress.org/core/handbook/coding-standards/php/>

- Zend Framework Coding Standard for PHP:
currently <http://framework.zend.com/manual/1.12/en/coding-standard.html>
(no Coding Standard has been published for ZF2 yet, so we can assume that
also applies for ZF2 code)

- Moodle Coding Style
<https://docs.moodle.org/dev/Coding_style>

(all retrieved as of the date of this posting)

> Looking at how its completely inconsistent though, I don't think this
> was GNU style indentation (my personal favorite actually).

I could live with GNU Style¹ if it would not make it so hard to tell
function/method calls apart. (I prefer Allman style [ibd.] except for
expressions, and I have started to insert the space before parameter lists
in declarations, to tell them apart from calls.)

Please trim your quotes to the relevant minimum. In particular, full quotes
are not acceptable. <https://www.netmeister.org/news/learn2quote.html>

_________
¹ <https://en.wikipedia.org/wiki/Indent_style#GNU_style>

Christoph M. Becker

unread,

Jan 17, 2015, 12:13:30 PM1/17/15

to

Thomas 'PointedEars' Lahn wrote:

> I could live with GNU Style¹ if it would not make it so hard to tell
> function/method calls apart. (I prefer Allman style [ibd.] except for
> expressions, and I have started to insert the space before parameter lists
in declarations, to tell them apart from calls.)

Wouldn't your former Allman style variation be 1TBS[ibd.]?

> _________
> ¹ <https://en.wikipedia.org/wiki/Indent_style#GNU_style>

--
Christoph M. Becker

Thomas 'PointedEars' Lahn

unread,

Jan 17, 2015, 1:09:23 PM1/17/15

to

Christoph M. Becker wrote:

> Thomas 'PointedEars' Lahn wrote:
>> I could live with GNU Style¹ if it would not make it so hard to tell
>> function/method calls apart. (I prefer Allman style [ibd.] except for
>> expressions, and I have started to insert the space before parameter
>> lists in declarations, to tell them apart from calls.)
>
> Wouldn't your former Allman style variation be 1TBS[ibd.]?

Yes, it would not, because 1TBS requires that the opening brace is written
on the same line as the declaration/control statement, while Allman style
requires that it is written one line below it, starting in the same column.

1TBS also makes no statement as to whether declarations should be written
differently than calls with regard to whitespace; given that it is described
as a variant of K&R style, and in the K&R example the formal parameter list
is not preceded by whitespace, it appears not to make such one.

Christoph M. Becker

unread,

Jan 22, 2015, 8:22:17 AM1/22/15

to

Thomas 'PointedEars' Lahn wrote:

> Christoph M. Becker wrote:
>
>> Thomas 'PointedEars' Lahn wrote:
>>> I could live with GNU Style¹ if it would not make it so hard to tell
>>> function/method calls apart. (I prefer Allman style [ibd.] except for
>>> expressions, and I have started to insert the space before parameter

^^^^^^^^^^^

>>> lists in declarations, to tell them apart from calls.)
>>
>> Wouldn't your former Allman style variation be 1TBS[ibd.]?
>
> Yes, it would not, because 1TBS requires that the opening brace is written
> on the same line as the declaration/control statement, while Allman style
> requires that it is written one line below it, starting in the same column.

Oops! I've mixed up expressions and statements.

>>> ¹ <https://en.wikipedia.org/wiki/Indent_style#GNU_style>