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

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

Related

Call to undefined function fetch_row()

Im connecting to database:
$con=mysql_connect("localhost","root","");
mysql_set_charset('utf8',$con);
mysql_select_db("mydb");
And when I try to get a row using within a for each with this code:
$question = fetch_row("SELECT * FROM `mytable` WHERE PyetjaNr = $i ORDER BY RAND() LIMIT 1 ");
Im getting this error:
Fatal error: Call to undefined function fetch_row()
Same code is working in my hosting server (mysql 5.5),
but not working in my localhost mysql (5.6),
Is problem to mysql version? can I do anything except upgrading to mysqli?
You may have missed this in the PHP manual (in which case, you should read the manual for functions you use), but the mysql_... functions are deprecated, and will almost certainly not even be in 5.7 when it comes out. They were replaced with the mysqli_... set of functions, so use those instead.
The PHP manual for mysqli::set_charset covers the initial setup you need, and getting data out of your db is then simply a matter of querying it the normal way.
Which usually means making use of prepared statements instead of just building your SQL as a string (because you want to be secure, you don't want to be Bobby Tables)
Wipe what you have now, redo it with mysqli functions. If your problem still exists, at least now you'll have modern code that people can comment on for putting in your question.

Switch large website from MySQL to MySQLi [duplicate]

This question already has answers here:
How to change mysql to mysqli?
(12 answers)
Closed 1 year ago.
I want to switch from MySQL to MySQLi, but I have a very large website.
I read that https://wikis.oracle.com/display/mysql/Converting+to+MySQLi could help me and I read How could I change this mysql to mysqli?. It says that I could replace most of the functions with just adding an 'i' to the function, and that I should start bughunting.
But my website is very complex and large, and it would take a very long time to check if everything works. So: what is the best way to switch from MySQL to MySQLi for a very large website?
Thanks!
There is no easy answer to your question as practically every simple way to do this involved doing things differently when the application was written.
If you have direct calls to mysql_* functions throughout your code and no database abstraction layer where you do your queries through a helper class or function then you will need to edit every command.
You cannot just get away with adding an i to commands like mysql_query as procedurally mysqli_query() requires the first parameter to be the link to the db where with mysql_query() if a connection was given at all, it was a second parameter.
Instead of just changing mysql_query(...) to mysqli_query($link,.....) I would recommend that there is no better time to put a db abstraction layer in place. So use functions eg sql_query() that actually process your queries so in future if you need to change DB again you can just update the db specific commands in one abstraction file. That way if you write a function that wraps mysqli_query then you could be able to simply rename your mysql_query() to your helper function and let the helper function worry about putting the link in there.
Whilst that is the simplest way, it will not bind parameters or prepare statements which is a major factor in preventing sql injection vulnerabilities
Once you have changed all these commands you need to test.
If you have no automated tests written then this is probably a good time to start writing them. Even though you will need to check that every change has worked, if you do it by automated test then you can avoid that pain in future.
you are taking right move becouse the mysql_* function are deprecated for latest php version. you should download a converter for this purpose...
see this and download...mysql to mysqli

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.

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