Early Bird Registration for DrupalCon Portland 2024 is open! Register by 23:59 PST on 31 March 2024, to get $100 off your ticket.
when use batch in the exporting to cvs excel process, some fields are missing. While not using batch, the problem is gone and the missing fileds are there.
Comment | File | Size | Author |
---|---|---|---|
#21 | test_view.txt | 3.1 KB | chx |
Comments
Comment #1
benjamin.pauley CreditAttribution: benjamin.pauley commentedSubscribe.
Seeing similar issue with export to xml.
Comment #2
benjamin.pauley CreditAttribution: benjamin.pauley commentedUpgrading 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
Comment #3
yang.wilby CreditAttribution: yang.wilby commenteddo you have any clue to fix this bug?
Comment #4
benjamin.pauley CreditAttribution: benjamin.pauley commentedMaking the title more descriptive.
Comment #5
upupax CreditAttribution: upupax commentedsubscribe.
Comment #6
benjamin.pauley CreditAttribution: benjamin.pauley commentedI 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).
Comment #7
emorency CreditAttribution: emorency commentedI 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.
Comment #8
upupax CreditAttribution: upupax commentedI'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.
Comment #9
upupax CreditAttribution: upupax commentedOk, 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.
Comment #10
upupax CreditAttribution: upupax commentedI'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:
while this is the output with Views 3.x-7.x-dev
as you can see there is no _field_data in the second one.
Comment #11
combicart CreditAttribution: combicart commentedsubscribe
Comment #12
Gr3fweN CreditAttribution: Gr3fweN commentedSubscribe...
Comment #13
jaguar_arx CreditAttribution: jaguar_arx commentedI 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.
Comment #14
Steven Jones CreditAttribution: Steven Jones commentedI think this must be a duplicate of #1160228: Field API fields are not exported
Comment #15
Rob_Feature CreditAttribution: Rob_Feature commentedAs 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.
Comment #16
imclean CreditAttribution: imclean commentedDev 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.
Comment #17
castroarguello CreditAttribution: castroarguello commentedI 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.
Comment #18
pichot CreditAttribution: pichot commentedInterestingly, 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.
Comment #19
zoraxI 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.
Comment #20
Denes.Szabo CreditAttribution: Denes.Szabo commentedI have a same problem with the latest 6.x-2.x dev version too.
Comment #21
chx CreditAttribution: chx commentedI 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.
Comment #22
chx CreditAttribution: chx commentedAh but 6.x-2.x-dev yes :(
Comment #23
xancthus CreditAttribution: xancthus commentedHas 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.
Comment #24
budgetstockphoto CreditAttribution: budgetstockphoto commentedI'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" :(
Comment #25
kardave CreditAttribution: kardave commentedThis 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.
Comment #26
lolcode CreditAttribution: lolcode commentedIn 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.
Comment #27
slefevre1 CreditAttribution: slefevre1 commentedI 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.Comment #28
kaleumakant CreditAttribution: kaleumakant commentedI 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.
Comment #29
kaleumakant CreditAttribution: kaleumakant commentedThis 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
Comment #30
rclemings CreditAttribution: rclemings commentedIn 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.
Comment #31
marleo CreditAttribution: marleo commented#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.
Comment #32
coolidfrez CreditAttribution: coolidfrez commented#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 !
Comment #33
giorgio79 CreditAttribution: giorgio79 commented#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...