1.8.1.0 to 2.3.5 ignored table gives "not found" MySQL error

[ae-smith]

Preconditions

1. Source: 1.8.1.0 community
2. Destination: 2.3.5 community
3. Local install using markshust docker setup (https://github.com/markshust/docker-magento)
4. Fresh install of m2
5. Ran migrate:settings
6. Ran migrate:data
7. Verified map.xml has ignored this table (prefix_yotpo_rich_snippets)

Steps to reproduce

This happens on a fresh 2.3.5 install, it runs for quite a while first, and then fails on the map step following CustomerAttributes.

Expected result

Map to proceed to next stage, as this table is ignored.

Actual result

`[2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: Url Rewrite Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: Log Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: Ratings Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: ConfigurablePrices step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: OrderGrids Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: Tier Price Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: SalesIncrement Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: integrity check][step: Inventory Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: setup triggers][step: Stage]: started [2020-05-30 21:58:46][INFO][mode: data][stage: data migration][step: EAV Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: volume check][step: EAV Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: data migration][step: Customer Attributes Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: volume check][step: Customer Attributes Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: data migration][step: Map Step]: started [2020-05-30 21:58:46][INFO][mode: data][stage: volume check][step: Map Step]: started 100% [============================] Remaining Time: < 1 sec In Mysql.php line 110:

SQLSTATE[42S02]: Base table or view not found: 1146 Table 'defaultdb.cabhubyotpo_rich_snippets' doesn't exist, query was: SELECT COUNT(*) FROM `cabhubyotpo_rich_snippets``

Additional notes

[m2-assistant[bot]]

Hi @ae-smith. Thank you for your report. To help us process this issue please make sure that you provided sufficient information.

Please, add a comment to assign the issue: @magento I am working on this

---

• Join Magento Community Engineering Slack and ask your questions in #github channel.

[ChameleonDevil]

Just for clarification: prefix_yotpo_rich_snippets , and the table error cabhubyotpo_rich_snippets doesn't look like its in the same format. (Underscore before yotpo, vs no underscore from generated data report). Unless your original statement was just a typo, this is most likely the error.

[ae-smith]

The m1 prefix used on this customer's db is set up like prefixtable_name

• as opposed to prefix_table_name.

On Mon, Jun 1, 2020 at 3:31 AM ChameleonDevil [email protected] wrote:

Just for clarification: prefix_yotpo_rich_snippets , and the table error cabhubyotpo_rich_snippets doesn't look like its in the same format. (Underscore before yotpo, vs no underscore from generated data report). Unless your original statement was just a typo, this is most likely the error.

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/magento/data-migration-tool/issues/819#issuecomment-636665565, or unsubscribe https://github.com/notifications/unsubscribe-auth/AM2YPYRXZEXHPICYV5A6E5DRUNKOFANCNFSM4NO35GJA .

[ChameleonDevil]

I assume you set both of these in config.xml correctly of your etc/magentoversion/version-number/ file: <source_prefix /> <dest_prefix />

Also you set this correct : <ignore> <document>core_website</document> </ignore>

You also have this option: in map.xml

<rename> <document>catalogsearch_query</document> <to>search_query</to> </rename>

I personally have only seen the import fail with 'TABLE NOT FOUND', when the maps are not set, never like your instance where you claim to have set the maps. I do not know if possibly the source_prefix, dest_prefix settings are ignored in some instances.