WordPress database error Unknown column 'Tables_in_' during search-replace

[edubacco]

Hi all,
using version 1.5, in a multisite installs with wp-content in custom location, if i try to launch
wp search-replace something someone
i get this error
WordPress database error Unknown column 'Tables_in_' in 'where clause' for query SHOW TABLES WHERE Tables_in_ IN [...]

[edubacco]

resolved, I have to add --all-tables, or specify the blogs.
https://make.wordpress.org/cli/

[schlessera]

This should probably not throw a "WordPress database error", but rather catch this error and provide helpful feedback.

Let's keep this open for further investigation.

[gitlost]

@edubacco was wondering if there were other errors thrown prior to the one reported above? I'm struggling to see how $wpdb->dbname could be empty. Also if you have the time could you post the wp-config.php for the site in question (with sensitive info redacted)? Ta either way!

[pdobrescu]

hi everyone. I'm getting the same error even on a single WordPress install, hosted on a custom setup. Adding --all-tables makes it work, but this shouldn't be necessary in this situation. Please let me know what kind of information you need about our setup in order to make it work out of the box. Thanks

[gitlost]

@pdobrescu thanks, could you post the wp-config.php being used (with sensitive info redacted)? Also could you expand on what the custom setup is?

[zacscott]

I get the same issue on a WooCommerce site, so don't think it is multi-site specific.

Here is the error I get;

$ wp search-replace "[redacted]" "[redacted]" --dry-run --url=[redacted]
WordPress database error Unknown column 'Tables_in_' in 'where clause' for query SHOW TABLES WHERE `Tables_in_` IN ('wp_users', 'wp_usermeta', 'wp_posts', 'wp_comments', 'wp_links', 'wp_options', 'wp_postmeta', 'wp_terms', 'wp_term_taxonomy', 'wp_term_relationships', 'wp_termmeta', 'wp_commentmeta', 'wp_woocommerce_payment_tokenmeta', 'wp_woocommerce_order_itemmeta') made by WP_CLI\Utils\wp_get_table_names
Success: 0 replacements to be made.

It is also resolved by using the --all-tables flag

[gitlost]

Thanks @zacscott , but could you post your wp-config.php please, it would help a lot. (The "fix" in a sense here is easy, just check whether $wpdb->dbname is empty, but how $wdb->dbname would be empty is puzzling to me, especially if no previous errors are thrown.)

[zacscott]

Hi @gitlost,

Here is our wp-config (sensitive info redacted).

We are using HyperDB which might be causing issues, though this is the same set up as we have used for other sites and we've never had this problem before.

Reader slave is configured via SLAVE_DB_HOST

<?php

if ( file_exists( dirname( __FILE__ ) . '/local-config.php' ) ) {

    define( 'WP_LOCAL_DEV', true );
    define( 'WP_ENV',       'local' );

    include( dirname( __FILE__ ) . '/local-config.php' );

    // Salt keys, [redacted]

} else if ( isset( $_SERVER['HTTP_HOST'] ) && strpos( $_SERVER['HTTP_HOST'], 'staging' ) !== false ) { // STAGING

    // TODO configure for staging

} else {

    define( 'WP_ENV',       'production' );
    define( 'WP_LOCAL_DEV', false );
    define( 'USE_MEMCACHE', true );
    define( 'WP_CACHE',     true );
    
    define( 'DB_NAME',       '[redacted]');
    define( 'DB_USER',       '[redacted]');
    define( 'DB_PASSWORD',   '[redacted]');
    define( 'DB_HOST', 	     '[redacted]');
    define( 'SLAVE_DB_HOST', '[redacted]' );
    
    define( 'WP_SITEURL',    'https://[redacted]/');
    define( 'WP_HOME',       'https://[redacted]/');
    
    define( 'WP_CACHE_KEY_SALT', md5( DB_NAME ) );
    
    ini_set( 'display_errors',      0 );
    ini_set( 'post_max_size',       '100M');
    ini_set( 'upload_max_filesize', '100M');
    
    define( 'WP_DEBUG',         false );
    define( 'WP_DEBUG_DISPLAY', false );
    define( 'SAVEQUERIES',      false );
    
    define( 'DBI_AWS_ACCESS_KEY_ID',     '[redacted]' );
    define( 'DBI_AWS_SECRET_ACCESS_KEY', '[redacted]' );
    
    $memcached_servers = array(
        array( '[redacted]', '11211' ),
        array( '[redacted]', '11211' )
    );
    
    // Salt keys, [redacted]

}

define( 'WP_CONTENT_DIR', dirname( __FILE__ ) . '/wp-content' );
define( 'WP_CONTENT_URL', 'https://' . $_SERVER['HTTP_HOST'] . '/wp-content' );

$table_prefix  = 'wp_';
define( 'DB_CHARSET', 'utf8' );
define( 'DB_COLLATE', '' );

define( 'WPLANG',          '' );
define( 'FS_METHOD',       'direct');
define( 'WP_MEMORY_LIMIT', '100M');

define( 'DISABLE_WP_CRON',            true );
define( 'DISALLOW_FILE_EDIT',         true );
define( 'AUTOMATIC_UPDATER_DISABLED', true );

if ( ! defined('WP_DEBUG') ) {
    define( 'WP_DEBUG', false );
    define( 'WP_DEBUG_DISPLAY', false );
}

if ( !defined( 'ABSPATH' ) )
    define( 'ABSPATH', dirname( __FILE__ ) . '/wp/' );
require_once( ABSPATH . 'wp-settings.php' );

[gitlost]

We are using HyperDB

Ah thanks @zacscott , that explains your case at least as it doesn't select a database on construction (ie call wpdb::db_connect()) and that isn't catered for in Utils\wp_get_table_names(). Will look at a fix tomorrow or over the weekend, ta!