English version broken

The "english" version is dosplaying japanese or chinese letters, and I don't understand anything :D

Empty sets (0 Rows affected) results

Most of these functions returns NULL when no results are matched by the query. I think these should be commented in functions like get_var, etc.

Possible error in examples on this page?

I think there are errors in this article but since they are the whole way through I thought I would check first before editing it.

In the examples, such as:

$name = $wpdb->get_var("SELECT cat_name FROM $wpdb->linkcategories WHERE cat_id=4");

I can only get this to work if I come out of the string before putting the $wpdb->table_name in, like this:

$name = $wpdb->get_var("SELECT cat_name FROM ".$wpdb->linkcategories." WHERE cat_id=4");

This makes logical sense to me too, but since it is the same in every example here, i thought I would query it first.

Additional

Came here to discuss the same issue. In my experience, removing $wpdb-> from within the query string also returns the correct result. For example, $mylink = $wpdb->get_row("SELECT * FROM $wpdb->links WHERE link_id = 10"); does not work, however; $mylink = $wpdb->get_row("SELECT * FROM links WHERE link_id = 10"); does work.

Thanks, John-Michael 05:49, 25 March 2010 (UTC)

This is perfectly valid and should work:

$mylink = $wpdb->get_row("SELECT * FROM $wpdb->links WHERE link_id = 10");

Make sure that you are using double quotes, and not single quotes. If you want to be clearer, you can always do this:

$mylink = $wpdb->get_row("SELECT * FROM {$wpdb->links} WHERE link_id = 10");

But it isn't necessary. J.D. Grimes 19:11, 7 June 2013 (UTC)

Why escaping?

Why this article suggests to escape every query when WordPress just do automatically escaping for all $_POST in wp-settings.php with:

// Escape with wpdb. $_GET = add_magic_quotes($_GET ); $_POST = add_magic_quotes($_POST ); $_COOKIE = add_magic_quotes($_COOKIE); $_SERVER = add_magic_quotes($_SERVER);

also if you escape again results in escaping also the escape and every time # of "\" grows in an exponential way.

It is true that WordPress currently does "magic-quotes"-like escaping of the user input. However, that may change in the future (we hope). Also, sometimes the slashes may be stripped out for some reason, and may need to be added back. And these are not the only places that data comes from. You might be using data from the database or another source that might not have been escaped. For this reason it is important to check your data sources and determine whether they can be trusted to always pass escaped data. See also wp_slash() and wp_unslash().

Jdgrimes 14:37, 28 December 2013 (UTC)

How to Access Eksternal Database ?

How WP access data from another database ?

I had open thread here >> http://wordpress.org/support/topic/249491

All column info is protected

One can't use get_col to output *anything* (same with get_results targeting column name), as the column info is now set to protected. And so, the claim that one can run "any" query on the db using $wpdb is now at best misleading.

var_dump($wpdb) returns, "...["result":protected]=> resource(38) of type (mysql result) ["col_info":protected]=> NULL..."

See: http://core.trac.wordpress.org/ticket/20838

I'm not sure what you mean. The get_col() method is meant to be used to retrieve the values stored in a column, not the name of the column or any other information about it. If you need to do that, then use get_col_info().

- J.D. Grimes 12:06, 30 June 2013 (UTC)

The wording describing checking value returned by the function query(...) for errors does not seem right

The text currently says " If a MySQL error is encountered, the function will return FALSE. Note that since both 0 and FALSE may be returned, you can use the equality == operator to test for falsy returns (i.e., a returned value that is logically FALSE). Using the identicality === operator may result in unexpected behavior as it compares the types returned in addition to the values...". That seems odd, isn't it the == operator that would confuse an error with a 0 result-set? Seems to me it is the == operator that would result in unexpected behavior, not the === operator, which would not confuse false with 0. Maratbn (talk) 05:54, 30 March 2015 (UTC)maratbn

I think this is confusing and should be clarified. Basically there are two different cases handled by this function: (1) queries that affect rows (INSERT, SELECT, etc.), and (2) queries that affect tables (CREATE, ALTER, TRUNCATE and DROP). For the former set, the return value will be an integer representing the number of rows affected. In the latter case it will be boolean true (assuming success). In both cases, a boolean false indicates failure. The suggestion to use the equality operator is probably intended to be in reference to situations where you are expecting at least 1 row to be affected by the query, so a 0 result would be an indication of failure (think SELECT or UPDATE).

However, I think you are correct and this advice is silly. If you are expecting rows to be affected, and none were, that might indicate a problem in your query. A case that comes to mind is you issue an UPDATE with criteria that no rows match. In this case you should still use the identity operator (===) to check for failures, and add other sanity checking for a 0 result depending on the case.

I'm not an expert in MySQL though, so maybe there are cases where you could issue an INSERT that would come back as successful, but wouldn't actually affect any rows and give you a 0? I don't see how that could be.

Also, query() should usually only be used for CREATE, ALTER, TRUNCATE and DROP statements anyway. (And CREATE and ALTER should probably be executed by dbDelta() in most situations.) There are already the update(), insert(), replace(), and get_*() methods for manipulating rows. So really, I think all of this is moot. We should consider moving the docs for query() to the bottom of the page, instead of this function being the most prominent one on the page.

-Jdgrimes (talk) 12:50, 30 March 2015 (UTC)

Updated. -Jdgrimes (talk) 13:07, 30 March 2015 (UTC)