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.

Comments

mikeryan’s picture

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.

mikeryan’s picture

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

No further information provided.

derhasi’s picture

Category:support» bug
Status:Closed (cannot reproduce)» Needs review
StatusFileSize
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.

mikeryan’s picture

Title:Problem with importing users - SQL error» D6 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...

mikeryan’s picture

Priority:Normal» Major
derhasi’s picture

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

mikeryan’s picture

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?

mikeryan’s picture

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

mikeryan’s picture

Status:Active» Fixed

Committed.

Status:Fixed» Closed (fixed)

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

claudiu.cristea’s picture

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:

<?php
     
// 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.

claudiu.cristea’s picture

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

Changed the title.

claudiu.cristea’s picture

Status:Active» Needs review
StatusFileSize
new2.31 KB

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

claudiu.cristea’s picture

StatusFileSize
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_*).

claudiu.cristea’s picture

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.

mikeryan’s picture

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.

mikeryan’s picture

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.