klawncare1239

Esmi,

This actually did help. I found the plugin that was causing me issues. Personally, it was Wp-answers plugin. Someone else might have a different issue.

Not sure why it didn’t occur to me to do that first. Maybe only that it took significant time to trouble-shoot each and every plugin to find the culprit.

SAme issue, except I don’t have the “call to undefined function” error. Just the “database had gone away” error.

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

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.

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.