Fields missing from .csv, .xml exports in batch mode

Subscribe.
Seeing similar issue with export to xml.

Upgrading to "major," as the fact that fields are missing from the exported view would seem like an issue that "[has] significant repercussions but [does] not render the whole system unusable."

Also, I can say that the same problem appears in version 6.3

Making the title more descriptive.

subscribe.

I wanted to report something I observed that fixed the problem, but for reasons I don't understand—it's not a fix, but it might be a workaround.

The fields that weren't appearing for me were all single-value fields (i.e. fields stored in the content_type_xyz table). Multiple value fields, stored in their own content_field_abc tables, appeared just fine. In addressing an unrelated issue, I created a new "ghost" content type and added the existing single-value fields that were being stored in the content_type_xyz table. Because those fields were now shared by multiple content types, they were moved out of the content_type_xyz table and into their own content_field_def, content_field_ghi, etc. tables.

After making that change, all of the fields appeared properly, INCLUDING some single-value fields that remained in the content_type_xyz table. I have no idea what happened here. (The fields that got moved into their own tables are custom CCK fields, some of which have LOTS of subfields. I don't know if that might be a factor.)

So, it's not a fix, but it might be a workable solution: make sure that the problem fields are stored in their own tables by adding those fields to more than one content type (and then adjust permissions to be sure none of your users ever has to see that the "ghost" content type is in the system: nobody should be creating nodes of that type).

I have the same issue with version 7.x-3.0-beta4.

In batch mode, my csv file has only the field "title" with a value. All other fields are empty.

If I don't use the batch mode, the csv file is ok.

I've noticed that running drush views-data-export on version 7.x-3.0-beta4, causes some problem in rendering fields.
I've report it here #1152208: Drush and advanced_render
Maybe the two issues are connected and the warning could provide some help in solving this issue.
I think that, since the module was working fine for me last week, the problem must be related to some Views changes.

Ok, I confirm: Views data export 7.x-3.0-beta4 works fine with Views Views data export 7.x-3.0-beta3, but breaks on last Views -dev releases.

I've noticed that _field_data is totally missing in the $rows output when using last views -dev.

This is the normal output with Views 7.x-3.0-beta4 of one $rows record:

  stdClass::__set_state(array(
     'vde_weight' => '1',
     'nid' => '208',
     'field_data_field_board_cf_node_entity_type' => 'node',
     'field_data_field_board_codut_node_entity_type' => 'node',
     'field_data_field_board_approv_node_entity_type' => 'node',
     'users_uid' => '143',
     'node_created' => '1305053105',
     '_field_data' => 
    array (

/* omissis: here there would be a long array with all the additional fields */

    ),
  ))

while this is the output with Views 3.x-7.x-dev

      stdClass::__set_state(array(
         'vde_weight' => '1',
         'nid' => '208',
         'field_data_field_board_cf_node_entity_type' => 'node',
         'field_data_field_board_codut_node_entity_type' => 'node',
         'field_data_field_board_approv_node_entity_type' => 'node',
         'users_uid' => '143',
         'node_created' => '1305053105',
      ))

as you can see there is no _field_data in the second one.

subscribe

Subscribe...

I hope this will be fixed. Views already released 7.x-3.0-RC-1 and views_data_export doesn't work with this views version.

I think this must be a duplicate of #1160228: Field API fields are not exported

As an FYI I'm actually seeing this same behavior in 6.x-2.0-beta4 as well. probably unrelated but I thought I'd chime in.

Dev version doesn't fix it for me ( http://drupal.org/node/1160228#comment-4681652 ).

More info:

- The view lists nodereference field, text field, node creation date and author
- The view uses one exposed filter (nodereference field)
- Previewing the CSV export shows all the field data
- Downloading in non-batch mode has all the field data
- Downloading in batch mode with no filter option set contains all data.
- Downloading in batch mode with exposed filter set contains all filtered data except the text field data. The text field title (label) is present.
- No errors are generated, the data is simply missing.

The text field is unique to the content type. This may make a difference as fields are stored differently if they are used in more than one content type.

Please let me know if you need any more info.

I am having the same problem with:
- 6.x.2.x-dev
- 6.x.2.0-beta5
The missing is a text field unique to the content type.

Interestingly, I have missing fields when I export with a non-superuser account. If I use a dev account, all my fields are exported. This is with version 7.x-3.0-beta5.

I use the 7 dev version.
i have a huge views with filter.
If I use batch export, the filters are ignored (php filter).
if I use without batch, the result is OK, but I can't get more than 20 lines (memory limit)
I precise that everything is all right when I look in the views preview.

I have a same problem with the latest 6.x-2.x dev version too.

I can't reproduce this in either 6.x-3.x view + 6.x-3.x views_data_export or 7.x-3.x the same. Attached the D6 Views export.

Ah but 6.x-2.x-dev yes :(

Has anyone figured out a workaround? I have Views Data Export 7.x-3.0-beta6, the latest dev, and this issue still exists. I'm also using:
Views 7.x-3.5
Views Dynamic Fields 7.x-1.x-dev
Views Export XLS 7.x-1.0
Views PHP 7.x-1.x-dev
Views Field View 7.x-1.0
Views Exposed Groups 7.x-1.0

My org is using our drupal site as our members database, so it's crucial that we get this search functioning.

I'm also seeing a similar issue with 6.x-3.3 and the lastest dev module for D6

for me this only affects whole rows of data, I either get all the fields or a load of empty fields. if I switch to TXT i get a line of "" "" "" empty fields, in csv it just shows up as a blank line

It only affects batch, I can get 2000 or so records out without batch and that's fine, with batch I see a few hundred records then perhaps 90 missing, then another few hundred or so then another sizable gap. Any help appreciated, including a workaround - for now I'm modifying my view to 'manually batch" :(

This is what exactly happened to me :(

Even if I set the view to output the first 10 items, the produced file contains no rows exept the headings. (tested: XML, XLS)

The preview below the view during edit seems okay.

In my case when the produced file contained no rows except the headings the solution was to change the "Exposed form style" setting from "Input Required" to "Basic" on the Data Export display only. It was not necessary to change it on the source display. It sounds like this is different from those who are experiencing some rows dropping out of the middle.

I am getting something similar with views 3.7 -- I have a view with a csv export. I have all the data in the columns, but the last one or two columns are missing the field labels. This is happening in both the preview and in the actual csv download. Whoops! Thought this was a views issue! I am getting this from views directly. Sorry.

I am also facing same issue of missing fields when i have selected batch process for exporting records. it is working fine for normal export (without batch export) but timesout due to large number of records.

This works for me when i removed exposed filters but still this problem exist's when you use exposed filters. any instant reply will be appreciated

In my case this turned out to be a configuration issue. Here are the details in case it helps someone else. It may be similar to https://www.drupal.org/node/1008264 ... I'll post a pointer there as well.

My export worked fine from the admin UI but when run from cron using drush, e.g.:

drush views-data-export viewname displayname outfile

... I wound up with several missing fields. All of them were profile2 fields. But some profile2 fields were output while others were not.

It turned out that one of two things was true for the problem fields:

1. "Make the content of this field private" was checked.
2. "Field visibility and permissions" was set to "Custom permissions."

I guess the explanation lies in the different credentials used when exporting from the UI instead of cron/drush. But changing the settings on the above items fixed the problem.

#6 works. So does not using batch mode, but I don't want users exporting a lot of data to hit a wall and not get their data. So sharing the fields in another unused content type - while still using batch mode - is the workaround with the least impact for me.

#30 works for me. I was guessing it was a reference field problem but changing the "Custom permissions" on that field in the referenced entity solved the problem. I'm using the 7.x-3.0-beta9 version.
Thank you very much rclemings !

#30 worked for me too! I set some fields visible to admin only and since drush is downloading the anonymous version those fields will be excluded...

Sorry for the lack of attention to your issue, please accept my apologies.

Drupal 7 is going to be end-of-life'd by the community in approximately 1 month.

As such, I am closing all non-critical looking, non-PHP compatibility issues for Views Data Export to tidy up the issue queues and reduce the noise. You can read about this on #3492246: Close down Drupal 7 issues.

If you feel like this issue has been closed by mistake, please do comment about re-opening it.
If you feel like the ticket is still relevant for the 8.x-1.x version of the module, then please search for a duplicate issue first, and if there really isn't one (and you've looked properly) then change the version on the ticket and re-open.

Thanks to everyone involved in this issue: for reporting it, and moving it along, it is truly appreciated.
The Drupal community wouldn't be what it is today without your involvement and effort, so I'm sorry that we couldn't get this issue resolved. Hopefully we'll work together in a future issue though, and get that one resolved :)