1

Trying to migrate Data from 1.9.3.8 to 2.2.3 I am running

    php bin/magento migrate:data -r -a vendor/magento/data-migration-tool/etc/opensource-to-opensource/1.9.3.8/config.xml

Getting error

    [Exception]                                                                                                                                           
    Notice: Undefined offset: 26 in /Applications/MAMP/htdocs/magentotest/vendor/magento/data-migration-tool/src/Migration/Step/Eav/Data.php on line 291 
1

Hope This Will Works:-

This happens when you re-try a migration

Insight 2 Truncating relevant (?) tables as in http://blog.titechnologies.in/magento-2-x-how-to-clear-test-data-before-production/ lead me to the next error - I believe the original issue is resolved.

Thanks :-)

| improve this answer | |
  • I have tried as suggested but now getting :- [PDOException] SQLSTATE[23000]: Integrity constraint violation: 1062 Duplicate entry '1-Migration_Default' for key 'EAV_ATTRIBUTE_SET_ENTITY_TYPE_ID_ATTRIBUTE_SET_NAME' – Virendra Kumar Sharma May 8 '18 at 10:54
  • 1
    Also Truncate:- catalog_eav_attribute, eav_attribute_group, eav_attribute_label, eav_attribute_option, eav_attribute_option_swatch, eav_attribute_option_value, eav_attribute_set, eav_entity, eav_entity_attribute, eav_entity_datetime, eav_entity_decimal, eav_entity_int, eav_entity_store, eav_entity_text, eav_entity_type, eav_entity_varchar, eav_form_element, eav_form_fieldset, eav_form_fieldset_label, eav_form_type, eav_form_type_entity – Divyesh May 8 '18 at 10:59
  • i have cleaned whole db and started migration again now getting below [Exception] Warning: Error while sending QUERY packet. PID=34518 in /Applications/MAMP/htdocs/magentotest/vendor/magento/data-migration-tool/src/Migration/ResourceModel/Adapter/Mysql.php on line 169 – Virendra Kumar Sharma May 8 '18 at 12:14
  • Perhaps $bind is multi-dimensional array It would be good if you put var_dump($bind) and var_dump($insertSql) right before $statement (github.com/magento/data-migration-tool/blob/master/src/…) and show here. If it is not tool big. Also you can run migration with -vvv param to see backtrace – Divyesh May 8 '18 at 12:24
1

Just for others who might bump into this one: it is a bug in the data migration tool. If the tool fails once for an attribute reason, when the tool reverts it does not put back the attribute set tables in the initial configuration. It leaves them in a state that will fail the migration, in an endless loop between 2 error states

  • m2's eav_attribute_set table ends up containing the "migration_" entries after the undefined offset error or any other error during a further substep of the eav process (hence causing the "duplicate" error next time)

  • m2's eav_attribute_set table ends up completely empty after this error (causing the "undefined offset" again)

on and on forever

For those struggling, I have managed to pass through by MANUALLY (in SQL) rebuilding the eav_attribute_set and eav_attribute_group tables in the database to have only the original entries, but with the IDs from after my first migration (taking out all the migration ones but leaving/putting back the missing default ones)

see my comments on https://github.com/magento/data-migration-tool/issues/204

it still happens in 2.2.5

| improve this answer | |
  • Experiencing this exact issue in version 2.3.4 of the data migration tool. Is the issue still present in the latest version? Can't find a way out of this loop..... – MagentoMac Apr 27 at 14:31
  • Hi @MagentoMac The issue was fixed in 2.3.3 (possibly 2.3.2) and it got good at "picking up where it left" though it is not impossible that there is a regression in 2.3.4 or some other issue that leaves the attributes in a messed up state. Check your eav_attribute_set and eav_attribute_group tables – iphigenie Apr 28 at 14:19
  • note that you also have to fix whatever issue caused the hang up in the first place, like a missing mapping etc. It takes a few rounds of trial and error – iphigenie Apr 28 at 14:20
  • Ok, thanks. I think we need to do more mapping, and then retry. It's a 10 year old M1 site and a lot of plugins and custom theme added in from legacy. Also custom attributes created by client that aren't "standard" so I guess we just need to re-work it all and then try again. Thanks for replies. – MagentoMac Apr 28 at 14:42
  • In spite of bugs and quirks it feels like magic when it works. Try running it with both -vvv for verbose but with the ignore errors settings, just to see the results. Then you'll get a better idea of what you want to explicitely map so it doenst migrate, and what you are missing. Many things from old modules are faster redone than migrating, esp if module maker is gone, or greedy, or made too many changes – iphigenie Apr 28 at 16:55

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.