WP_Error( 'wpdb_get_table_charset_failure' ) thrown when doing "SHOW TABLES LIKE %s"

[datafeedr.com]

When attempting to check if a DB table exists, the "wpdb_get_table_charset_failure" error is being thrown. Here's where I believe the error is being thrown (wp-includes/wp-db.php:2235~2238):

		$results = $this->get_results( "SHOW FULL COLUMNS FROM `$table`" );
		if ( ! $results ) {
			return new WP_Error( 'wpdb_get_table_charset_failure' );
		}

My PHP error log has "WordPress database error Table 'private.wp_dfrpswc_temp_post_ids_by_set_id' doesn't exist for query SHOW FULL COLUMNS FROM wp_dfrpswc_temp_post_ids_by_set_id".

I believe the issue is related to the get_table_charset() method being called before the new table has been created.

I'm running WP 4.2-RC1-32175. This is my custom code which generates the error:

$table_name = $wpdb->prefix . 'dfrpswc_temp_post_ids_by_set_id';
$query = $wpdb->prepare( "SHOW TABLES LIKE %s", $table_name );
if ( $wpdb->get_var( $query ) != $table_name ) {
	dfrpswc_create_table();
}

Let me know if you need any additional information.

Thanks
Eric

[netweb]

#32033 was marked as a duplicate.

[pento]

32029.diff​ doesn't try and check the collation of tables when it's a query that really doesn't need it.

@datafeedr.com: Would you be able to test this patch against your code, please?

[valendesigns]

I ran into this very same thing earlier today with one of my plugins. Even though this is definitely an issue that should be solved in Core, I also think there is a better way to see if a table exists. Try the following instead:

$table_name = $wpdb->prefix . 'dfrpswc_temp_post_ids_by_set_id';
if ( ! in_array( $table_name, $wpdb->tables() ) ) {
	dfrpswc_create_table();
}

@pento I tested the patch and can confirm it solves the issue.

[nacin]

Replying to valendesigns:

$table_name = $wpdb->prefix . 'dfrpswc_temp_post_ids_by_set_id';
if ( ! in_array( $table_name, $wpdb->tables() ) ) {
	dfrpswc_create_table();
}

Nope. $wpdb->tables() isn't based on the database. This will never return true.

[valendesigns]

That sucks! Well, disregard the comment. Patch works in any case.

[pento]

In 32232:

WPDB: When deciding if a query needs extra sanity checking based on collation, we can quickly return if it's a query that will never return user data.

Fixes #32029.

[pento]

In 32233:

WPDB: When deciding if a query needs extra sanity checking based on collation, we can quickly return if the query is entirely ASCII characters.

See #32029.

[pento]

In 32234:

WPDB: When deciding if a query needs extra sanity checking based on collation, return early when we can. Merges [32232] and [32233] to the 4.1 branch.

See #32029.

[pento]

In 32235:

WPDB: When deciding if a query needs extra sanity checking based on collation, return early when we can. Merges [32232] and [32233] to the 4.0 branch.

See #32029.

[pento]

In 32239:

WPDB: When deciding if a query needs extra sanity checking based on collation, return early when we can. Merges [32232] and [32233] to the 3.9 branch.

See #32029.

[pento]

In 32240:

WPDB: When deciding if a query needs extra sanity checking based on collation, return early when we can. Merges [32232] and [32233] to the 3.8 branch.

See #32029.

[pento]

In 32241:

WPDB: When deciding if a query needs extra sanity checking based on collation, return early when we can. Merges [32232] and [32233] to the 3.7 branch.

See #32029.

[datafeedr.com]

Replying to pento:

@datafeedr.com: Would you be able to test this patch against your code, please?

@pento The patch works for me, too. Thanks for the fix!

Eric