MySQL said: Table 'db-name.craft_freeform_submissions_form-name' doesn't exist

[mariuswestgaard]

What happened?

After upgrading both craft and freeform simultaneously from latest v4 versions to latest v5 versions, and successfully running php craft up I'm getting an error on the Freeform: Purging Old Spam Submissions queue job:

Base table or view not found: 1146 Table 'nortek-staging.craft_freeform_submissions_subscription_hubspot_7'

But, I see the table in the database. Also, when trying to open the table (which is present in the table overview list) in Sequel Ace, I get this error: MySQL said: Table 'nortek-staging.craft_freeform_submissions_subscription_hubspot_7' doesn't exist

This is true for all the new forms tables.

Errors and Stack Trace (if available)

No response

How can we reproduce this?

1. Upgrade from latest craft 4 and freeform 4, to latest craft 5 and freeform 5
2. After php craft up is done, let the queue finish. The purge job then fails, with the discribed message

Freeform Edition

Pro

Freeform Version

5.7.2

Craft Version

5.5.2

When did this issue start?

After upgrading from older Freeform version

Previous Freeform Version

4.13.0

[kjmartens]

Sorry for the trouble you're experiencing, @mariuswestgaard.

Are you noticing any other issues with Freeform? E.g. saving forms in the form builder, submitting the form on the front end, viewing and editing submissions in the control panel?

Is it possible for you to send us the following (to [email protected]):

• A copy of your complete database we can review it to see what might be causing this issue.
• A copy of your Freeform 4 / Craft 4 database to review/compare
• A screenshot of the Freeform Diagnostics page in the control panel

Thanks 🙂

[mariuswestgaard]

@kjmartens, thanks for looking in to it!

Yes, I'm experiencing issues with the form handles being changed (to camelCase, not keeping the old formatting), and I can't view the submissions. When I'm accessing the submissions page, I get the same error as the first one I described in the issue.

Sorry, I can't send the database due to sensitive information, but let me know if I should send you some specifics from it, or send some more info about the database.

Here's the diagnostics view:

[mariuswestgaard]

@kjmartens
I just noticed that the database table before the upgrade command is named craft_freeform_submissions_subscription_hubspot_7 while it is changed to craft_freeform_submissions_subscriptionHubspot_7 this in the updated database. Then it makes sense that the error in console says the table craft_freeform_submissions_subscription_hubspot_7 is not available, because it's not. So somewhere in the migration there is something that partially changes the handles and table names, but did not fully finish it, or it happens unintentionally.

[alexmglover]

@kjmartens II'm having this issue, but it's only if the submission form contains a number before the migration. As an example covid19 being the form name, and it's looking for freeform_submissions_covid_1_9_8, so seemingly splitting the numbers up incorrectly. The table the migration created was freeform_submissions_covid19_8, which is correct.

[kjmartens]

@mariuswestgaard

Yes, I'm experiencing issues with the form handles being changed (to camelCase, not keeping the old formatting), and I can't view the submissions. When I'm accessing the submissions page, I get the same error as the first one I described in the issue.

Is this inside the form builder? And what is the formatting you're trying to use? Craft does have some limits to which characters are not allowed, such as -, etc.

I just noticed that the database table before the upgrade command is named craft_freeform_submissions_subscription_hubspot_7 while it is changed to craft_freeform_submissions_subscriptionHubspot_7 this in the updated database. Then it makes sense that the error in console says the table craft_freeform_submissions_subscription_hubspot_7 is not available, because it's not. So somewhere in the migration there is something that partially changes the handles and table names, but did not fully finish it, or it happens unintentionally.

The correct format should be snake case... something like freeform_submissions_my_test_form_1. It's hard to say what happened here though. I tested the migration again last week and it was correctly using snake case for the final database table name.

You mention you can't send the database, but would it be possible to just send the Freeform database tables at least? And if that is an issue as well, is it possible to send just the Freeform tables with the submission data cleared from the tables? That would at least give us an idea why/if the migration might have choked on your setup. 🙂

[kjmartens]

@alexmglover

@kjmartens I'm having this issue, but it's only if the submission form contains a number before the migration. As an example covid19 being the form name, and it's looking for freeform_submissions_covid_1_9_8, so seemingly splitting the numbers up incorrectly. The table the migration created was freeform_submissions_covid19_8, which is correct.

As ugly as it looks, the database tables use snake case, which means that it should be freeform_submissions_covid_1_9_8. If the migration converted it to freeform_submissions_covid19_8, then that could be an issue. Out of curiosity, if you temporarily rename the form handle in the form builder to something else and save, does it correct the issue?

In the meantime, I will log the issue and we'll check into it. 🙂

[mariuswestgaard]

@kjmartens

Is this inside the form builder? And what is the formatting you're trying to use? Craft does have some limits to which characters are not allowed, such as -, etc.

No, the form handles was changed during the migration process. All our forms was using snake_case before the migration, but they came out of migration with camelCase handles, and changed table names as described in my last comment.

The correct format should be snake case... something like freeform_submissions_my_test_form_1. It's hard to say what happened here though. I tested the migration again last week and it was correctly using snake case for the final database table name.

Yes, the tables and form handles was using snake case before the migration.

I'll try to export the db without submissions, and remove all other tables than the freeform tables. I guess you want post-migration database?

[kjmartens]

@mariuswestgaard I would prefer the pre-migration database to see what you started with, and if possible, the post-migration database as well. You can send that to [email protected]. 🙂

[mariuswestgaard]

Okay, I'll check what I can do tomorrow.
Btw, the issue fixed itself by manually changing all form handles back to snake case. That also updated the database submission table names to snake case

[kjmartens]

Thanks @mariuswestgaard. I figured that would be the case. 🙂