PDOException: SQLSTATE[HY000]: General error: 1364 Field 'wid' doesn't have a default value

I have same issue and i replace given below in SQL query but still not get solve pages not working but
I cannot able to edit After login content, confi

Hey Sharma007, I have the exact same issue too. Were you able to figure it out?

The most likely cause of this issue (and similar ones with other tables) is that your SQL got truncated when being imported. Typically this happens when you're importing your database via PHPMyAdmin or similar software, and the request times out. Sometimes, though, it happens when there's some kind of typo or issue in the SQL file. I've also seen it when there's nothing wrong with the SQL file itself, but for some reason an old table is not being fully dropped in the database before re-importing.

Either way, when an error occurs during import, the remaining SQL statements are not executed. Since the errors are often towards the end of the file, most of the statements are run, resulting in a database that appears to be complete, but which is missing many of the later statements that set default values and incriminators for tables. The lack of those features on the tables is what's resulting in the errors folks are reporting here.

You can try fixing your tables one by one, but it's very difficult. A better option is to:

1) Clear your database completely (i.e. drop all tables) and verify there are no lingering tables.
2) Re-import your SQL file, ideally from the command line to ensure there are no network issues.
3) Watch for any errors during import. If there are errors, you may need to manually remove the offending SQL statements in the import file.

If you can get the SQL to import with no issue (and assuming you've got a complete SQL dump to begin with), your issues should resolve.

On Drupal 10.2.5, PHP 8.2.17, MySQL db 8.0.36-28:

I have a similar problem, but it's not because I imported the database.
When searching on Google, I have seen that the error can occur when the site is a subsite of another site. That is exactly the case for me.
I have tested two sites that are subsites and two other sites that are main sites.
On my subsites the problem occurs, but on my main sites there is no problem. (The provider is the same: Simply.com).
I have attached a file with error examples similar to the above.

Hi

I was able to fix this issue:

Drupal\Core\Database\DatabaseExceptionWrapper</em>: SQLSTATE[HY000]: General error: 1364 Field &#039;item_id&#039; doesn&#039;t have a default value: INSERT INTO {queue} (name, data, created) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2);

This is because of queue table item_id.
What i did is: to browse the table queue and change item_id as unique and auto increment. you can do it via query OR form phpmyadmin table structure.

All admin links are working to me now..

Thank you!

Astonishing that kienan91's 9 year old SQL fix worked for me!

8 years ago steps to reproduce this problem were asked for and none have been provided. Can anyone supply that?

This was also reported against different tables, and in Drupal 7 and Drupal 10.2. Comment #49 suggests this is caused during import of a database. Can anyone who has experienced this confirm that an import of the site database was done before the error started happening. In other words, we still need steps to reproduce.

Since we need more information to move forward with this issue, I am leaving the status to Postponed (maintainer needs more info). If we don't receive additional information to help with the issue, it may be closed after three months.

Thanks!

It is a very rare issue to happen with Drupal and it happened to me with aws migration process.

Fixing the watchdog table and queue table is not enough cause there may be other tables broken like in my case with the domain module and so on.

I did some research and I came up with a possible solution designed to fix the schema for all tables in the broken database.

Please help me to test his approach.

This approach to fix schema in broken DB using ddev with both databases → .

Here is the overview of the solution described in my gist

SELECT 
    CONCAT(
        'ALTER TABLE `', t.TABLE_NAME, '` ',
        GROUP_CONCAT(
            CASE
                WHEN c.COLUMN_NAME IS NULL THEN CONCAT('ADD COLUMN `', sc.COLUMN_NAME, '` ', sc.COLUMN_TYPE, ' ', 
                    IF(sc.IS_NULLABLE = 'NO', 'NOT NULL', 'NULL'), 
                    IF(sc.COLUMN_DEFAULT IS NOT NULL, CONCAT(' DEFAULT ', IF(sc.COLUMN_DEFAULT = 'CURRENT_TIMESTAMP', sc.COLUMN_DEFAULT, CONCAT('''', sc.COLUMN_DEFAULT, ''''))), ''),
                    IF(sc.EXTRA != '', CONCAT(' ', sc.EXTRA), '')
                )
                WHEN sc.COLUMN_TYPE != c.COLUMN_TYPE OR sc.IS_NULLABLE != c.IS_NULLABLE OR sc.COLUMN_DEFAULT != c.COLUMN_DEFAULT OR sc.EXTRA != c.EXTRA 
                THEN CONCAT('MODIFY COLUMN `', c.COLUMN_NAME, '` ', sc.COLUMN_TYPE, ' ', 
                    IF(sc.IS_NULLABLE = 'NO', 'NOT NULL', 'NULL'), 
                    IF(sc.COLUMN_DEFAULT IS NOT NULL, CONCAT(' DEFAULT ', IF(sc.COLUMN_DEFAULT = 'CURRENT_TIMESTAMP', sc.COLUMN_DEFAULT, CONCAT('''', sc.COLUMN_DEFAULT, ''''))), ''),
                    IF(sc.EXTRA != '', CONCAT(' ', sc.EXTRA), '')
                )
            END
            SEPARATOR ', '
        ),
        ';'
    ) AS alter_statement
FROM 
    information_schema.TABLES t
JOIN 
    information_schema.COLUMNS c ON t.TABLE_NAME = c.TABLE_NAME AND t.TABLE_SCHEMA = c.TABLE_SCHEMA
LEFT JOIN 
    information_schema.COLUMNS sc ON t.TABLE_NAME = sc.TABLE_NAME AND c.COLUMN_NAME = sc.COLUMN_NAME AND sc.TABLE_SCHEMA = 'source_database'
WHERE 
    t.TABLE_SCHEMA = 'target_database'
    AND (sc.COLUMN_TYPE != c.COLUMN_TYPE OR sc.IS_NULLABLE != c.IS_NULLABLE OR sc.COLUMN_DEFAULT != c.COLUMN_DEFAULT OR sc.EXTRA != c.EXTRA)
GROUP BY 
    t.TABLE_NAME
HAVING 
    alter_statement IS NOT NULL;

ddev mysql < schema_export.sql
ddev mysql < alter_statements.sql

Sounds like a potential valid bug.

Maybe need a test case to show the issue?