$wpdb Not Working

What is $wpdb->value? I can’t find any reference to it anywhere. And I’m sure there is no $wpdb->wp_cimy_uef_data. Are you trying to select the ‘value’ column from the ‘wp_cimy_uef_data’ table? in that case you want:

"SELECT value FROM wp_cimy_uef_data WHERE user_id =  ".$user_id." AND field_id = 1"

Or, better, use $wpdb->prefix like so:

"SELECT value FROM ".$wpdb->prefix."cimy_uef_data WHERE user_id =  ".$user_id." AND field_id = 1"

You can’t just make up $wpdb elements. The only ones you can use are the ones here.

Well, I appreciate your input and will try the change the you suggest. However, I’m not trying to “make up” elements. I saw references to wpdb being used in that way on other websites. Originally, I had my code similar to what you suggest, but it wasn’t working. So, I tried it the other way and that didn’t work.

However, I believe, when I had my code as you suggest, I didn’t yet have the “global” statement included – didn’t know I needed it. I’ll give yours a shot.

Also, this won’t work..

echo $result;

You can’t echo data returned as an array or object, anything more then a string and you’ll get an error or warning, if you need to print out data in testing, then for arrays and objects use print_r ..

print_r( $var );

Or (easier to read).

print '<pre>';
print_r( $var );
print '<pre>';

Ok, for those who may read this post looking for a similar answer, here’s what worked for me.

First, a thank you to apljdi for pointing me in the right direction. In the end my code ended working as below:

<?php global $current_user;
      get_currentuserinfo();
      $user_id = $current_user->ID;

global $wpdb;

$result = $wpdb->get_var("SELECT value FROM ".$wpdb->prefix."cimy_uef_data WHERE user_id =  ".$user_id." AND field_id = 1");
echo $result;

?>

In order to find the correct record in my custom table, I needed to get the current logged-in user’s ID. So, that’s there the “current_user” stuff comes in at the top. I placed the logged-in user’s id into the $user_id variable.

Then, in order to use the $wpdb function (or whatever you call it), I had to make it global (which isn’t exactly made clear in alot of documentation I saw – but, without it, it didn’t seem to work). So, the “global $wpdb” was necessary for me to make it work.

Beyond that, the following line is slightly adjusted from what was provided by “apljdi”. In it, he/she had suggested the correct formatting of the “SELECT” phrase, but had not indicated that I should change get_row to get_var in my code.

Maybe, depending upon what I wanted, that change wouldn’t have been necessary. But, I was looking for the exact contents of the “value” column, within the ONE record that would meet the “where” criteria I set. Thus, it appears that get_var was more appropriate, and that is what worked for me.

The “SELECT” code simply indicates to grab the contents of the “value” column within the “cimy_uef_data” table (which is actually pre-fixed by “wp_” in my database and is why the “.$wpdb->prefix.” portion is included – I could have just used “wp_cimy_uef_data” instead), but only for records that meet the “where” criteria. The value in the user_id column must be equal to the $user_id variable that I set earlier AND the value within the field_id column must equal 1. If both of those criteria are met for a certain record (row) within my database table, the contents of the “value” table are grabbed and displayed by the “echo” statement.

I know this was probably a little wordy, but hopefully it helps someone. Many times I find posts like these on forums and such, but without any explanation of why/how the suggestion worked.

Oh yes apologies, for get_var, echo is valid, consider this post a retraction for the above, my bad… ??

The part about ‘making up elements’ wasn’t really intended to offensive. Just trying to point out that were using elements not in the wbdb class. You can use syntax like in your code but it only works for core WP tables– wp_posts, wp_users, etc– so maybe that is what you saw on other websites.

And you’ll need the global in most cases, I’d say, so keep that in mind.

I had to make it global (which isn’t exactly made clear in alot of documentation I saw – but, without it, it didn’t seem to work). So, the “global $wpdb” was necessary for me to make it work.

This bit has more to do with the way PHP in general works than with the way WordPress works, so maybe that is why it wasn’t stressed is the docs.

Maybe, depending upon what I wanted, that change wouldn’t have been necessary.

Right. It does depend on the kind of output you want. get_row will return an array or an object. get_var will return a string. get_var may not give you what you want if the query returns more than one row, so if that’s a possibility you need to use get_col or get_results.

which is actually pre-fixed by “wp_” in my database and is why the “.$wpdb->prefix.” portion is included – I could have just used “wp_cimy_uef_data” instead

The $wpdb->prefix is mostly for portability to sites where people have set the database prefix to something other than ‘wp_’.

Thanks for the assistance and extra explanation – both for me and for others that may see this post.