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.


Status:Active» Postponed (maintainer needs more info)

So, 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.

Version:» 7.x-2.x-dev
Status:Postponed (maintainer needs more info)» Closed (cannot reproduce)

No further information provided.

Category:support» bug
Status:Closed (cannot reproduce)» Needs review
new1.51 KB

I got the same/similar 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[error]
use near 'FROM
content_type_profile f
WHERE  (vid = '139')' at line 1

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.

Title:Problem with importing users - SQL errorD6 content_profile import doesn't work with separate field tables
Component:Code» D6-specific
Status:Needs review» Needs work

Ah, so the root cause is not handling the separate field tables for content profiles, as we do for normal nodes. Let's fix that...

Priority:Normal» Major

Yes 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 ;)

Priority:Major» Normal
Status:Needs work» Postponed (maintainer needs more info)

Actually, 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?

Status:Postponed (maintainer needs more info)» Active

Reproduced 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).

Status:Active» Fixed


Status:Fixed» Closed (fixed)

Automatically closed -- issue fixed for 2 weeks with no activity.

Status:Closed (fixed)» Active

This 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:

// The main column for the field should be rendered with
      // the field name, not the column name (e.g., field_foo rather
      // than field_foo_value).
$field_info = $this->version->getSourceFieldInfo();
      foreach (
$field_info as $field_name => $info) {
        if (isset(
$info['columns']) && !$info['multiple'] && $info['db_storage']) {
$i = 0;

see $info['db_storage'] condition.

Title:D6 content_profile import doesn't work with separate field tablesCCK fields stored in own tables not in source row
Assigned:Unassigned» claudiu.cristea

Changed the title.

Status:Active» Needs review
new2.31 KB

Here's a patch that add also columns from content_field_* tables.

new2.95 KB

This second patch take care about node types that have no CCK table (content_type_*) but only CCK field tables (content_field_*).

Hmm... 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.

Status:Needs review» Needs work

In 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.

Status:Needs work» Closed (fixed)

In 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.