Support for Drupal 7 is ending on 5 January 2025—it’s time to migrate to Drupal 10! Learn about the many benefits of Drupal 10 and find migration tools in our resource center.
I am trying to import users using example module. There is probably some problem with the Content Profile source, which I am trying to use, because it end up with followin error:
Migration failed with source plugin exception: SQLSTATE[42000]: Syntax error or access violation: 1064 You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'FROM content_type_clovek f WHERE (vid = '370')' at line 1
...where content_type_clovek is the machine name of my content profile content type. Can you please point me to the right direction? I am using the latest version of D2D and Migrate. Thanks very much.
Comment | File | Size | Author |
---|---|---|---|
#14 | migrate_d2d-field-tables-1766044-14.patch | 2.95 KB | claudiu.cristea |
#13 | migrate_d2d-field-tables-1766044-13.patch | 2.31 KB | claudiu.cristea |
#3 | migrate_d2d_content_profile-1766044-3.patch | 1.51 KB | derhasi |
Comments
Comment #1
mikeryanSo, take a look at the content_type_clovek table in your source - is it missing the vid column? As far as I know, CCK's content_type_* tables should always have a vid column.
Comment #2
mikeryanNo further information provided.
Comment #3
derhasi CreditAttribution: derhasi commentedI got the same/similar error:
The problem is that the code expects a handable field to be present, but a content profile might e.g only have multi value fields (that are not handable at the moment).
Attached there's a patch that might solve the problem.
Comment #4
mikeryanAh, so the root cause is not handling the separate field tables for content profiles, as we do for normal nodes. Let's fix that...
Comment #5
mikeryanComment #6
derhasi CreditAttribution: derhasi commentedYes the root problem seems to be that the content profile implementation does not (want, @see line 211
&& !$info['multiple']
) to implement multi value fields.But we should fix that concrete issue first, as It simply creates a buggy SQ, so users having this problem, still could use d2d. So maybe you could implement the patch, as long as we'll get multivalues in ;)
Comment #7
mikeryanActually, the code does handle fields whether they're in the separate table or in the main content_type table. I did find that if the content profile type hasn't had any db_storage fields created, there's no content_type_ table, so I committed a patch to make sure the table is there. However, the problem you're reporting seems to indicate that your content_type tables don't have a vid column, and using the latest D6 CCK I cannot reproduce that scenario - is it possible you have an old version of CCK on the D6 site?
Comment #8
mikeryanReproduced the problem, quite by accident - it will happen when all content_profile fields are in separate field tables, the query ends up being "SELECT FROM {content_type_profile} f...". We have to make sure we skip querying if we end up not doing any addField() calls, simple enough (afraid it's too late for the 2.0 release though).
Comment #9
mikeryanCommitted.
Comment #11
claudiu.cristeaThis is still a bug. Fields stored in separate tables (of pattern
content_field_<fieldname>
are not added to the source records.This happens because they are filtered out here:
see
$info['db_storage']
condition.Comment #12
claudiu.cristeaChanged the title.
Comment #13
claudiu.cristeaHere's a patch that add also columns from
content_field_*
tables.Comment #14
claudiu.cristeaThis second patch take care about node types that have no CCK table (
content_type_*
) but only CCK field tables (content_field_*
).Comment #15
claudiu.cristeaHmm... It seems that CCK table (
content_type_*
) is always created even if there's no field inside but only fields stored in the CCK field tables (content_field_*
). So, #13 seems the right patch.Comment #16
mikeryanIn the future, please don't reopen long-closed issues, open a fresh issue.
The node.inc query() intentionally only joins the primary field table, because individual tables may have multiple values which on joining would result in multiple rows for a given node. The individual tables are handled in d6.inc - if there's a bug preventing them from getting migrated in your case, the issue will be in DrupalVersion6::getSourceValues() - you'll find the individual field tables queried in the vicinity of line 214.
Comment #17
mikeryanIn working on #1971778: Migrate the image data (alt, title and description) by the Wizard, I have confirmed that as a general rule the content_field_<fieldname> data is included in the source row. Restoring the status of this issue - if you can reproduce and describe a specific issue with migrating field data, please open a fresh issue.