Using latest Feeds and Feeds SQL Module as well as Drupal-7.14.

Everything was working well until I upgraded from 7.12 to 7.14 recently, now feeds no longer imports on cron, and when I do a manual import, it looks to import the correct number of items, but the nodes that are created are blank.

The only obvious error I'm seeing is

Notice: Undefined index: FeedsSQLParser in FeedsSource->getConfigFor() (line 584 of /var/aegir/platforms/mrcintranet/sites/all/modules/feeds/includes/FeedsSource.inc).
Notice: Array to string conversion in FeedsFetcherResult->sanitizeRaw() (line 70 of /var/aegir/platforms/mrcintranet/sites/all/modules/feeds/plugins/FeedsFetcher.inc).

Have tried attaching to a content type, and using a standalone form. When setting the query in the SQL parser, it is able to pull back a sample, so I'm guessing that it's unlikely to be any kind of connection problems. I've tried deleting and redoing the importer. Uninstalling Feeds/FeedsSQL completely and even updating to the latest dev release.

Sample Feeds config is as follows:

$feeds_importer = new stdClass();
$feeds_importer->disabled = FALSE; /* Edit this to true to make a default feeds_importer disabled initially */
$feeds_importer->api_version = 1;
$feeds_importer->id = 'antibodies';
$feeds_importer->config = array(
  'name' => 'Antibodies',
  'description' => '',
  'fetcher' => array(
    'plugin_key' => 'FeedsSQLFetcher',
    'config' => array(
      'databases' => array(
        'intranet' => 'intranet',
        'default' => 0,
      ),
    ),
  ),
  'parser' => array(
    'plugin_key' => 'FeedsSQLParser',
    'config' => array(
      'query' => 'SELECT * FROM mrcintranet.ANTITABLE WHERE DSTT=1;',
      'database' => 'mrcintranet',
      'mapping' => array(
        'ANTINAME' => 'ANTINAME',
        'BLEED' => 'BLEED',
        'DEVELOPMENT' => 'DEVELOPMENT',
        'DSTT' => 'DSTT',
        'DUNUM' => 'DUNUM',
        'FULLNAME' => 'FULLNAME',
        'GLEADER' => 'GLEADER',
        'IMMSEQ' => 'IMMSEQ',
        'LONGNAME' => 'LONGNAME',
        'MRC' => 'MRC',
        'PDF' => 'PDF',
        'PHOSPEP' => 'PHOSPEP',
        'REAGENTYPE' => 'REAGENTYPE',
        'SHEEPNO' => 'SHEEPNO',
        'SYNONYMS' => 'SYNONYMS',
        'UPDATED' => 'UPDATED',
        'YEAR' => 'YEAR',
        'id' => 'id',
      ),
      'results' => '',
    ),
  ),
  'processor' => array(
    'plugin_key' => 'FeedsNodeProcessor',
    'config' => array(
      'content_type' => 'antibodies',
      'expire' => '-1',
      'author' => 0,
      'mappings' => array(
        0 => array(
          'source' => 'ANTINAME',
          'target' => 'field_antiname',
          'unique' => FALSE,
        ),
        1 => array(
          'source' => 'BLEED',
          'target' => 'field_antitable_bleed',
          'unique' => FALSE,
        ),
        2 => array(
          'source' => 'DEVELOPMENT',
          'target' => 'field_antitable_development',
          'unique' => FALSE,
        ),
        3 => array(
          'source' => 'DUNUM',
          'target' => 'field_dunum',
          'unique' => FALSE,
        ),
        4 => array(
          'source' => 'FULLNAME',
          'target' => 'title',
          'unique' => FALSE,
        ),
        5 => array(
          'source' => 'GLEADER',
          'target' => 'field_antitable_gleader',
          'unique' => FALSE,
        ),
        6 => array(
          'source' => 'IMMSEQ',
          'target' => 'field_antitable_immseq',
          'unique' => FALSE,
        ),
        7 => array(
          'source' => 'LONGNAME',
          'target' => 'field_antitable_longname',
          'unique' => FALSE,
        ),
        8 => array(
          'source' => 'PDF',
          'target' => 'field_antitable_pdf',
          'unique' => FALSE,
        ),
        9 => array(
          'source' => 'PHOSPEP',
          'target' => 'field_antitable_phospep',
          'unique' => FALSE,
        ),
        10 => array(
          'source' => 'REAGENTYPE',
          'target' => 'field_antitable_reagenttype',
          'unique' => FALSE,
        ),
        11 => array(
          'source' => 'SHEEPNO',
          'target' => 'field_antitable_sheepno',
          'unique' => FALSE,
        ),
        12 => array(
          'source' => 'SYNONYMS',
          'target' => 'field_synonyms',
          'unique' => FALSE,
        ),
        13 => array(
          'source' => 'YEAR',
          'target' => 'field_antitable_year',
          'unique' => FALSE,
        ),
        14 => array(
          'source' => 'id',
          'target' => 'guid',
          'unique' => 1,
        ),
      ),
      'update_existing' => '2',
      'input_format' => 'plain_text',
    ),
  ),
  'content_type' => '',
  'update' => 0,
  'import_period' => '1800',
  'expire_period' => 3600,
  'import_on_create' => 1,
  'process_in_background' => 0,
);

Anyone got any ideas where I'm going wrong? I'm not sure whether it's a Feeds problem or a Feeds_SQL problem but thought I'd try here first.

Comments

blearyboy’s picture

Having exactly the same issue; everything was working fine until upgrading to 7.14.

millaraj’s picture

@blearboy

Has everything just stopped working, or are you getting any errors? Was this a production system, or still in development? In other words, was anything else changed when you did the upgrade, or was it just the upgrade?

thugshades’s picture

I am having the same issue. I had it working, added something to the query and now some of the fields are blank on import. They worked (at least one did) until upgrade. Anyone know of a way to get this working again? Unfortunately for me we only have one environment and this will hold me up.

mfgr’s picture

I've just started using Feeds, but I'm getting the same result when importing a csv file as instructed: just empty nodes. I have Drupal 7.14 installed, so it could be related to that, but I don't know. I saw the video on Lynda.com with the instruction and was well impressed, but after fiddling with this module for two hours, I'm just frustrated.

DerekL’s picture

Same here, same error message.

Notice: Undefined index: FeedsSQLParser in FeedsSource->getConfigFor() (line 584 of /var/www/vhosts/brazilcham.com/httpdocs/sites/all/modules/feeds/includes/FeedsSource.inc).

7.14, SQL import now returning blanks upon blanks, have a "dev" environment still on 7.10 with no issues.

Unfortunately, production and stage are on 7.14 due to the security fixes...We're dead in the water.

Edit:

I just went through and recreated my imports using Feeds Database ( http://drupal.org/project/feeds_db ). Same issue.
Blank imported nodes. This is totally killing my joo joo right now.

Any official word?

thugshades’s picture

Priority: Normal » Major

I was hoping that the update that just came out would fix it, but I still have the same issue. Anyone have ANY leads on this?

JulienF’s picture

Version: 7.x-2.x-dev » 7.x-2.0-alpha5
Category: support » bug
Priority: Major » Critical

I'm having the same issue. For a very simple feed Importer. whenever I import it correctly counts the number of records but it creates empty nodes (not a single field contains information).

I think this is a top priority as long as it totally disable the core functionality of the module.

I'm ready to help and would appreciate any guidance on where the code happens following what I am doing:

Importing a CSV with the following field types:

Text field
Text Area
Float
Date

JulienF’s picture

Category: bug » support
Priority: Critical » Major

What a shame, we were not selecting the right delimiter... and opening the file to import in Excel didn't show it with the delimiter !

We still had some issue with date format and decimals but we could easily deal with this thanks to the hook available in the module.

For me the problem (which was not a problem) is solved :-)

I reset the status of this issue as it was initially

thugshades’s picture

After playing around and almost giving up on feeds being able to do what I needed anymore, I was finally able to get it working. Not sure if this will help anyone else, but I read a blurb on the Migrate module that there was an issue with CASE, and so I went ahead and made sure the fields that weren't working were re-done and all lower case (in content type and in the mapping and in the query). I *BELIEVE* this is what fixed my problem and wanted to let others here know, in case that would help!

chipway’s picture

Using SELECT FIELDNAME as fieldname, FIELDNAME2 as fieldname2, ... FROM MYTABLE;
as query should solve this issue.

Hope this helps.

Outdoor Ed’s picture

Version: 7.x-2.0-alpha5 » 7.x-2.0-alpha8
Category: support » task
Priority: Major » Critical

This one drove me absolutely crazy for about 3 weeks. I was trying to import a legacy site from SQL Server into Drupal using Feeds SQL. With the Query in Mixed Case it would run fine on the SQL Parser step and show my records to import. Then when I would run the import page one empty record would come across. I figured that if the SQL string was correct enough to work in the Parser it was fine. Nope. I changed my entire query string to lower case and it imported all the records fine. This really should be added to the Feeds SQL documentation so that people like me don't waste huge amounts of time. Thanks for this post. It's saved me another 3 weeks of agony.

greggles’s picture

Title: Import not running on cron, manual import results in blank nodes. » Update documentation to talk about lower case vs. upper case for the sql string
Version: 7.x-2.0-alpha8 » 7.x-2.x-dev
Component: Code » Documentation
Priority: Critical » Normal
Status: Active » Postponed (maintainer needs more info)

Is anyone still able to reproduce this issue?

Does the lower case/upper case thing fix it for everyone? Marking "needs more info" for these questions and downgrading the priority since it's been a long time with no new comments, maybe it was fixed in code somehow.

tterranigma’s picture

Status: Postponed (maintainer needs more info) » Closed (works as designed)