Using mysql_* functions with a mysqli connection - php

I was wondering if the older mysql_* functions provided with php will work with a mysqli connection.

No, the mysql_* functions were used only with the mysql driver.
There are new functions created for using with mysqli which you can read more about here.
The new method is object oriented instead of the old functional style.

The mysql extension uses resources for the link identifier:
There are two resource types used in the MySQL module. The first one is the link identifier for a database connection, the second a resource which holds the result of a query.
MySQLi does not provide any resources:
This extension has no resource types defined.
Consequently, when doing
$link = mysqli_connect('127.0.0.1', 'user', 'secret', 'test');
$result = mysql_query("SELECT 'it works' FROM dual", $link);
you will get
Warning: mysql_query() expects parameter 2 to be resource, object given
and $result will be NULL.

No, they won't, they're two entirely difference resources.
Unless you're trying to do a drop-in replacement of a MySQL connection with a MySQLIi connection, there's not much need for you to worry about this, unless you can't stand writing the i every time :-P
Remember though that you can still connect to newer MySQL databases with the mysql_* commands.

Related

Upgrading to MySQLi - As easy as swapping out mysql for mysqli?

After a lot of responses on a number of different posts I've seen, I'm stopping using mysql and am trying to upgrade my site to use mysqli.
My question is, based on the functions of mysql that I list below (which are the ones I currently use) can I do a blanket replace on 'mysql_' for 'mysqli_' and not break functionality? I've already done some research on each of these functions and none of the mysqli versions look like they wouldn't work, but I just need to be sure before I swap them all out.
query
fetch_array
connect
select_db
error
real_escape_string
num_rows
fetch_assoc
free_result
Check out this SO question which provides answers to at least most of your functions.
For example:
mysql_connect will be replaced by mysqli_connect
mysql_error will be replaced by mysqli_error and/or mysqli_connect_error, depending on the context
mysql_query will be replaced by mysqli_query

Using Mysqli: Is there a way to not have to connect to the database every single query?

I have just begun working with MYSQLi instead of MYSQL, and I have run into a huge annoyance: having to connect to the database every single query and such. Why do I have to do this now when I didn't in old MYSQL? Or is there a way not to have to do this?
A couple examples:
Mysql:
mysql_query("SELECT id FROM table");
Now in Mysqli I always have to do:
mysqli_query($db, "SELECT id FROM table");
also I have to do this with:
mysqli_last_id($db);
and
mysqli_real_escape_string($db);
I have tried to find the answer to this all night, but I can't find anything.
There are some things to clarify
You don't have to connect every time. Connecting to database is different thing, one when you're calling mysqli_connect() and you should do it only once per application.
So, you're talking of just using connection resource variable.
Yes, you have to pass it in every function. Not a big deal, nothing to talk of.
The only issue could be with variable scope. Use global $db; inside a function.
Moving to mysqli just mechanically, using new functions old way makes absolutely no sense. If you want to keep using mysqli_real_escape_string in the application code - don't bother with transition at all and keep with mysql.
The only reason (quite weak though) for move - to use prepared statements.
Mysqli's support for prepared statements is awful
So, better quit mysqli and go for PDO
Nevertheless, using raw API functions, be it mysql, mysqli or PDO, is ugly. One have to adopt some abstraction library to be used in the application code instead.
Yeap, don't use mysql_* functions, they are deprecated. Use PDO instead
http://www.php.net/manual/es/pdo.construct.php
$pdo = new PDO(/* Connection options */);
$rows = $pdo->query("SELECT * FROM table")->fetchAll(PDO::FETCH_OBJ);
foreach ($rows as $row) {
print_r($row);
}
$pdo->query("INSERT INTO table SET field1 = 'value1'");
Give a try to DALMP Database Abstraction Layer for MySQL using PHP. is uses pure mysqli and connects to database only when needed, when possible get the results from the cache, with out touching the database.
Examples of using the cache can be found here Cache & prepared statements

Find/replace mysql_ to mysqli_ makes code nonfunctional

So as I'm sure anyone who's been a regular on SO has noticed, the mysql_ functions are going to be deprecated and it is suggested that one use mysqli_ or PDO instead. Thus, I decided to transition over to mysqli by doing a simple find/replace in my code, replacing every mysql_ with mysqli_. This seemed to work okay in Dreamweaver, and I got no syntax errors or anything. All the new mysqli_ functions were colored blue, meaning that they were recognized as valid functions.
However, when I saved everything and ran the code, I noticed that any code having to do with mysql had become nonfunctional. Undoing the replace solved the problem.
Is my server perhaps not supporting the mysqli functions? I know that it's running php 5 and mysql 5. Is there perhaps something else that you have to add to the code? What am I missing?
It's a good time to switch now, since PHP 7.0 removed the ext/mysql functions from core.
Consider the following legacy code
$res = mysql_query($sql);
The mysql_ functions were lazy, in that it would use whatever connection was open. But mysqli_ is not only not lazy, it's an object, not a connection resource (which is what mysql_connect() would return). Look at these lines here for connecting to the database
$mysqli = new mysqli('host', 'username', 'password', 'db');
$mysqli = mysqli_connect('host', 'username', 'password', 'db');
Both of them give you the same thing...
Returns an object which represents the connection to a MySQL Server.
Yes, that's right. Even the procedural connection function returns an object. The simplest way to use it is directly in is object form
$mysqli->query($sql);
The procedural functions are simply wrappers for this. But they are NOT lazy. Check out the difference
mysqli_query($mysqli, $sql);
The single largest gotcha in this (why a simple find and replace of mysql_ with mysqli_ fails) is that most of the mysqli_ functions require you to pass the connection object as the first argument. It's also important to note that results are objects as well (mysqli_result class), although their procedural counterparts only require the result set so you can simply find/replace those.
Just to be complete, there's one other gotcha that's less common (this is really old code): mysql_result. This function has no equivalent in mysqli_. You should switch to the full row return functions like mysqli_fetch_assoc($result)
you might wanna check out http://wiki.hashphp.org/PDO_Tutorial_for_MySQL_Developers , which should tell you just about all you need to know about migrating mysql_ code, but to PDO, not MySQLi..
you Have to know There are many issues might had be done when you were replacing your code.
Check the installation of mysqli here.
check the configuration of mysqli here.
check the DB connection in tow ways :
** simple connection like natimysql:
$con = mysqli_connect("localhost","my_user","my_password","my_db");
But Now You have to use it like that
mysqli_query($con,"SELECT * FROM Table"); // $con is the connection which is must for executing the sql query
**my best way is dealing with it as new mysqli object like that :
$con = new mysqli('localhost', 'user', 'pass', 'demo');
now you will do it like that :
$sql = "SELECT * FROM Table";
$con->query($sql);
if you checked every query that you had done before You must find one of these errors specially the errors in the 3rd point
you can take a tour in its tutorial here , here or here
Surprised nobody has mentioned that the mysql_ and mysqli_ functions are not exact parallels, therefore a search and replace is bound to fail. Also mysqli_ will generally insist on the database connection parameter (when used in procedural mode, which is what you're aiming fo), where mysql_ would just grab whatever connection had been opened earlier in the code.
If you have debugging enabled, you should be able to work through the errors.
The most common 'gotcha' is that there is no mysqli equivalent of mysql_result(), which people often used when getting a single result. I'd be willing to bet your code is scattered with "mysqli_result()" calls, which will all fail.
That's the basic fix. The 'good' fix might be to use a dedicated class for all your SQL calls, so that there are only a handful of uses of the mysqli functions in your entire codebase, and all in a single file. That way when you refactor you don't need to search through mountains of files all with a variety of different uses of various mysqli functions.
If you "Need some authoritative sources for MySQL -> MySQLi migration" I can recommend a website called Google ;-) Type in "MySQL -> MySQLi migration".
For instance, this 'for Dummies' page shows you the differences between the various functions that you'll need to address to get your code working.
http://www.dummies.com/how-to/content/how-to-convert-mysqli-functions-to-mysql-functions.html
mysql_ functions are now deprecated
Nope, they aren't yet
I decided to transition over to mysqli by doing a simple find/replace in my code
the problem most likely lies in the fact that mysqli functions has reverse parameters order and require connection resource explicitly.
Nevertheless, even if you succeed with such a bulk replace, it will do not a slightest good to your code, so, you'd better keep it as is, despite of some errr... overenthusiastic campaign on this site.
There is no reason to hurry. You have at least 5 years until you'd start notice some inconvenience.
The goal of all this noise about mysql functions is not for changing some API to another but for making usual PHP codes slightly more sensible and safe. You won't reach neither of these goals with just search and replace - so, there is no reason to do it at all.
What you really need is a some intelligent way of handling queries, encapsulated in some library class, which will not only improve your experience with running SQL queries but also will move all the API functions into one place where they can be easily replaced to whatever API some folks will decide to force you to use.

PHP5 mysqli vs mysql config files

I know this sounds very stupid indeed, but I find mysqli prepared statements and its object-oriented approach attractive so I plan on converting some of my past doodles from mysql to mysqli.
Here it is... The question
In mysql I used to have a configuration file, for example included in every file that needs the database (i.e. require('sys/dbconfig.php');)
I am not sure if I need to do this in mysqli, or do so as others say, open a connection when you need it, close it when you don't need it (i.e. stick $mysqli = new mysqli($host, $user, $pass, $database); everywhere it needs database transactions.
I do it like that:
config.php
define("DB_HOST", "127.0.0.1");
define("DB_NAME", "demo");
define("DB_USER", "root");
define("DB_PASS", "root");
database.php
// include database constants
include_once("config.php");
// create db connection
$db = new mysqli(DB_HOST, DB_USER, DB_PASS, DB_NAME);
now you can make SQL statements via
$result = $db->query("SELECT x FROM y;");
MySqlI comes in 2 flavours: procedural and object oriented.
When you use the procedural style everything stays the same as in mysqli_.
You are refering to the object oriented style and there the configuration is different .. more object oriented actually. That means that you have to create a new instance of mysqli and use its methods to get the job done.
Note: when using mysqli_ the same way as mysql you will have the same problems with SQL injection. You should use mysqli in combination with prepared queries and parameter binding.
Mysqli opens the connection when it is instantiated with new mysqli(...) (so does PDO).
During a PHP session you should not need to open/close connections to the database because the duration of a PHP session (for normal websites/webapps) is less than 1 second.
Forcing the equivalent of mysql_connect/mysql_close multiple times in the code can be helpful only in long running scripts that do not need an active connection for their entire duration.
The number of separate mysql connections allowed per mysql user is limited depending on the configuration of you server.
If you have some script that runs a long time and that will likely intersect many other scripts, you may use-up all of the allowed connections per user and thus block other users.
I would suggest (as a simple approach) to instantiate mysqli in a file that you will include everywhere you need db access use the variable you stored the mysqli object everywhere you need it using global $db.
I tend to create constants in a config file like Panique does.
I also create an App class with a static method fetch_db that contains the code for the connection. Then whenever I need a db connection I just call App::fetch_db().
I can post the code and a little more explanation later this afternoon when I get home.

what mysqli functions to use instead of mysql?

This will probably sound pretty dumb. I've got a mysql function containing the following...
#mysql_connect()
#mysql_select_db($databaseName,$link);
mysql_query($sql,$link);
mysql_error()
mysql_fetch_array($result,MYSQL_ASSOC)
mysql_num_rows($result)
Can I just bung an i after mysql like this...
#mysqli_connect
mysqli_query($link, $sql);
mysqli_error($link)."]";
mysqli_fetch_array($result,MYSQLI_ASSOC))
mysqli_num_rows($result);
The first two I know are ok but what about the others? I'm not sure those functions actually exist as straight swap mysqli versions. Can't seem to find much info about them.
What would there mysqli equivilent be?
Can I just use mysqli_connect and mysqli_query but use the old mysql functions for the others? Do they work together like that
Here is the "book" area of the PHP manual showing you EVERY mysqli function available. Your assumption is pretty much correct, a lot of the naming convention applies with just adding 'i' but to be sure that it exists, take a peak here: http://php.net/manual/en/book.mysqli.php
One of the strengths of the MySQLi extension is it's more object oriented. I'd recommend moving to that method as it's easier to work with.

Categories