Back to DigiConsent

Database Errors

DigiConsent stores configuration settings, consent records, and operational data in your WordPress database. When database operations fail, you might see error messages, settings that won’t save, consent records that don’t persist, or even the plugin failing to activate. Database errors can be intimidating because they often involve technical error messages and require server-level troubleshooting, but understanding common database issues and their solutions makes these problems manageable.

WordPress uses MySQL or MariaDB databases to store all site data. DigiConsent creates its own database tables or uses WordPress’s options system to store data. Problems can occur during installation, updates, or normal operation when the database becomes corrupted, runs out of space, has permission issues, or encounters configuration problems.

Enabling WordPress Debug Mode

Before diagnosing database errors, enable WordPress debug mode to see detailed error messages. By default, WordPress hides errors from visitors for security, but administrators need to see errors to troubleshoot effectively.

Enabling debug mode: Access your WordPress installation via FTP or your hosting file manager. Open the wp-config.php file located in your WordPress root directory (the same directory containing wp-content, wp-admin, and wp-includes). Find these lines near the top of the file:

define('WP_DEBUG', false);

Replace them with:

define('WP_DEBUG', true);
define('WP_DEBUG_LOG', true);
define('WP_DEBUG_DISPLAY', false);
define('SCRIPT_DEBUG', false);

This configuration logs errors to a debug.log file in the wp-content directory without displaying them to visitors. After making changes that should trigger errors, check wp-content/debug.log for detailed error messages including database errors.

Important: Disable debug mode on production sites after troubleshooting. Debug logs can grow large and potentially contain sensitive information. Set WP_DEBUG back to false when you’re done diagnosing issues.

Common Database Error Messages

“Error establishing a database connection”: This critical error means WordPress cannot connect to your database at all. Your entire site will be down, showing only this error message. Causes include incorrect database credentials, the database server being down, or network connectivity problems between your web server and database server.

Solution: Verify database credentials in wp-config.php. The file contains database connection information:

define('DB_NAME', 'database_name');
define('DB_USER', 'database_user');
define('DB_PASSWORD', 'database_password');
define('DB_HOST', 'localhost');

Contact your hosting provider to confirm these credentials are correct. The database name, username, and password must match what your hosting control panel shows. DB_HOST is usually localhost but some hosts use different values like an IP address or hostname.

If credentials are correct, your database server might be down. Contact your hosting provider’s support—they can check if the database server is running and restart it if needed.

“Table doesn’t exist” errors: DigiConsent might try to access database tables that haven’t been created. This happens if plugin installation didn’t complete successfully or if database tables were accidentally deleted.

Error messages look like: Table 'database_name.wp_digiconsent_logs' doesn't exist

Solution: Deactivate and reactivate DigiConsent. WordPress plugins run activation routines when activated that create necessary database tables. Deactivating doesn’t delete settings (they’re preserved in the database), and reactivating forces the activation routine to run again, recreating missing tables.

If reactivation doesn’t create tables, the database user might lack permissions to create tables. Contact your hosting provider to ensure the database user has CREATE TABLE privileges.

“Duplicate entry” errors: Attempting to insert data that violates unique key constraints causes duplicate entry errors. For example: Duplicate entry '123' for key 'PRIMARY'

This indicates database corruption or logic errors where code tries to insert the same record twice. It shouldn’t happen during normal operation.

Solution: Check debug logs for what triggered the duplicate entry. If it happens consistently when performing a specific action, report it to DigiConsent support as a bug. If it’s a one-time occurrence, the database might have had a temporary inconsistency that resolved itself.

Database Table Corruption

Database tables can become corrupted due to server crashes, improper shutdowns, hardware failures, or software bugs. Corrupted tables cause unpredictable errors, data loss, or plugin functionality failures.

Symptoms of corruption: Random errors that don’t consistently reproduce, data disappearing, settings not saving intermittently, or error messages mentioning “crashed,” “marked as crashed,” or “repair” in the debug log.

Checking for corruption: Access phpMyAdmin through your hosting control panel. This provides a web interface for managing your MySQL database. Navigate to your WordPress database and look for DigiConsent tables (they typically start with your table prefix followed by “digiconsent”).

Select the DigiConsent tables (check the boxes next to them) and choose “Repair table” from the dropdown menu at the bottom of the table list. phpMyAdmin will attempt to repair any corruption. If repair succeeds, test DigiConsent functionality to verify issues are resolved.

Optimization after repair: After repairing tables, optimize them to reclaim unused space and improve performance. In phpMyAdmin, select tables and choose “Optimize table” from the dropdown. This reorganizes table data for better efficiency.

Prevention: Regular database backups protect against corruption. Use a backup plugin like UpdraftPlus or BackupBuddy, or use your hosting control panel’s backup features. Quality hosting with reliable hardware reduces corruption risk, so consider upgrading from bargain shared hosting if corruption is recurring.

Database Permission Issues

The database user account that WordPress uses needs specific permissions to perform operations. Insufficient permissions cause errors when DigiConsent tries to create tables, insert data, or modify existing records.

Required permissions: The WordPress database user should have these permissions at minimum:

  • SELECT – Read data from tables
  • INSERT – Add new records
  • UPDATE – Modify existing records
  • DELETE – Remove records
  • CREATE – Create new tables (needed during plugin installation)
  • ALTER – Modify table structures (needed during plugin updates)
  • DROP – Delete tables (sometimes needed during uninstallation)
  • INDEX – Create and modify indexes

Most hosting setups grant all these permissions by default, but restrictive security configurations might limit permissions.

Checking permissions: In phpMyAdmin, click on your database in the left sidebar, then click the “Privileges” tab. This shows which users have access and what permissions they have. The database user defined in wp-config.php should be listed with full permissions for your WordPress database.

If permissions are limited, contact your hosting provider. They can grant necessary permissions through their control panel or via command line if you have SSH access.

Error messages indicating permission problems: Look for errors like:

  • Access denied for user 'username'@'host'
  • CREATE command denied to user
  • ALTER command denied to user

These clearly indicate permission issues rather than bugs or configuration problems.

Database Size and Resource Limits

Shared hosting plans often impose database size limits. If DigiConsent logs consent records extensively and your database grows beyond the limit, write operations fail.

Checking database size: In phpMyAdmin, the database list shows each database’s size. Compare your WordPress database size to your hosting plan’s database size limit (check your hosting documentation or contact support for this limit).

If you’re approaching or exceeding the limit, you’ll get errors when DigiConsent tries to log consent records or save settings. Errors might say “quota exceeded” or “database full.”

Solution – Clean up old data: If DigiConsent stores consent logs, old logs might consume significant space. Check plugin settings for log retention options. Configure the plugin to automatically delete logs older than a certain period (like 6 or 12 months). Compliance typically requires keeping consent records for a limited time, not indefinitely.

Manually delete old consent records if the plugin doesn’t offer automatic cleanup. In phpMyAdmin, navigate to the consent logs table and use the SQL query tab to delete old records:

DELETE FROM wp_digiconsent_logs WHERE date < DATE_SUB(NOW(), INTERVAL 12 MONTH);

This deletes logs older than 12 months. Adjust the table name (wp_digiconsent_logs) and date column (date) to match your actual table structure. Always backup before deleting data.

Solution - Upgrade hosting: If database size limits are too restrictive for your needs, upgrade to a hosting plan with larger or unlimited database sizes. Quality managed WordPress hosts typically offer generous database limits.

Plugin Update Database Migration Failures

When DigiConsent updates to a new version, it might need to modify database table structures to support new features. These database migrations can fail, leaving the plugin in a broken state between old and new versions.

Symptoms: After updating DigiConsent, you see database errors, missing features, or the plugin dashboard shows an error notice about database updates needed. Debug logs show errors related to ALTER TABLE or schema changes.

Solution - Retry migration: Deactivate and reactivate the plugin to force database migration routines to run again. Plugin activation hooks typically check database schema and update it if needed. This often resolves failed migrations.

Before deactivating, backup your database. While deactivation shouldn't delete data, having a backup ensures you can recover if something goes wrong.

Manual migration: If automatic migration continues failing, check if DigiConsent provides documentation or SQL files for manual database updates. Some plugins include upgrade scripts in their folders that you can run manually through phpMyAdmin.

Contact DigiConsent support if migration failures persist. They can provide specific SQL queries to manually apply schema changes or investigate why automatic migration fails.

Character Encoding and Collation Issues

Databases use character encoding (like UTF-8) to store text. Mismatched character encoding between database, tables, and application code causes problems with special characters, foreign languages, or emojis.

Symptoms: Text appears as question marks (�), garbled characters, or squares. Foreign language text displays incorrectly. Emojis don't save or display as ??.

Checking encoding: In phpMyAdmin, click on your database and check the "Collation" column. It should show utf8mb4_unicode_ci or utf8mb4_general_ci. The utf8mb4 character set supports full Unicode including emojis and complex characters.

Older databases might use utf8 (without mb4), which has limitations. If DigiConsent tries to store emojis or certain special characters in a utf8 database, it fails.

Solution - Convert to utf8mb4: WordPress includes a database upgrade tool for converting to utf8mb4. In WordPress admin, go to Tools → Database. If an upgrade is available, you'll see a notice. Click the upgrade button to convert your database to utf8mb4.

Alternatively, in phpMyAdmin, you can manually convert tables. Select a table, click "Operations" tab, and under "Table options" change collation to utf8mb4_unicode_ci. Repeat for all DigiConsent tables.

Important: Backup before converting character sets. While conversion is usually safe, having a backup ensures you can recover if problems occur.

Query Performance and Slow Queries

Inefficient database queries slow down your site. If DigiConsent performs complex or unoptimized queries, page loads become sluggish or even timeout.

Identifying slow queries: Enable the Query Monitor plugin (available free from WordPress.org). This plugin shows all database queries on each page load, their execution time, and which code triggered them. Load pages where DigiConsent runs and check Query Monitor for slow queries (typically those taking over 0.1 seconds are concerning).

If you see DigiConsent queries taking excessive time, the plugin might need optimization or your database might need indexes.

Solution - Database indexing: Database indexes speed up queries by creating searchable structures for frequently queried columns. If DigiConsent queries large consent log tables without proper indexes, queries are slow.

Properly designed plugins create necessary indexes during installation. If performance is poor, indexes might be missing. Contact DigiConsent support about performance issues—they can advise on which indexes should exist and provide SQL to create missing ones.

Solution - Query caching: Use a persistent object cache (Redis or Memcached) to cache query results. Install Redis Object Cache or Memcached Object Cache plugin and configure your server with the respective caching service. This dramatically reduces database load by caching frequently accessed data.

Backup and Recovery

Before attempting any database repairs or modifications, always create a backup. Database operations can go wrong, and having a backup means you can restore to a working state.

Creating manual backups: In phpMyAdmin, select your WordPress database, click "Export" at the top, choose "Quick" export method and "SQL" format, then click "Go" to download the backup file. Store this file safely on your computer.

Alternatively, use your hosting control panel's backup features (cPanel has backup wizard, Plesk has backup manager, etc.). These create complete backups including files and database.

Automated backups: Install a backup plugin like UpdraftPlus, BackupBuddy, or Duplicator. Configure automated daily or weekly backups to cloud storage (Dropbox, Google Drive, Amazon S3). This ensures you always have recent backups without manual effort.

Restoring from backup: If database modifications cause problems, restore your backup. In phpMyAdmin, select your database, click "Import," choose your backup SQL file, and click "Go." This replaces current database content with the backup.

Warning: Restoring backups loses any changes made after the backup was created. If you backup in the morning and restore in the evening, you lose the day's changes (new content, comments, orders, etc.). Only restore backups when current database state is corrupt or broken beyond repair.

When to Contact Hosting Support

Some database issues require hosting provider intervention. Contact support for:

  • "Error establishing a database connection" when credentials are correct
  • Database server crashes or downtime
  • Permission issues you cannot resolve through phpMyAdmin
  • Database size limit increases
  • Performance issues traced to server-level database configuration
  • Repeated corruption suggesting hardware problems
  • Assistance with database recovery after severe corruption

Quality hosting providers have database administrators who can diagnose and fix server-level issues beyond your control. Provide them with specific error messages from debug logs to help them troubleshoot effectively.

Database Error Prevention

Prevent database errors through good practices:

  • Keep regular automated backups
  • Use quality hosting with reliable hardware and database servers
  • Keep WordPress, plugins, and themes updated (updates include bug fixes that prevent database issues)
  • Monitor database size and clean up old data regularly
  • Optimize database tables monthly using phpMyAdmin or optimization plugins
  • Use persistent object caching to reduce database load
  • Test plugin updates on staging sites before updating production

Database errors seem complex, but systematic troubleshooting using error logs, phpMyAdmin, and the techniques in this guide resolves most issues. Understanding database basics empowers you to maintain a healthy, performant WordPress installation where DigiConsent and all plugins function reliably without database-related interruptions.

Similar Articles

Back to DigiConsent