I agree.

see also bug 380245

there are some issues with CSV exports that I ran into when working on a database program of mine (however, they can be resolved easily).

Excel XML Spreadsheet format is more bulletproof.  I requested that feature in  Bug 592401, but CSV format is also necessary for many applications, so I am not ruling out CSV in favor of XML, but saying have both!  both formats are relatively simple to write.

CSV format can be accomplished by simply separating the fields with a comma.  However, this means that none of the fields can contain a comma.  in order to prevent broken records, a substitution must be made, such as replacing commas in fields with underscores and then notifying the user that this has been done.  

detecting commas in a string is as easy as writing a 
int strcpos(char * str, char c) {
    int index, l=strlen(str);
    for (index=0; index < l; index++) {
        if (c==str[index]) return index; //found
    }
    return -1; //failure
}
and calling if (-1==strcpos(field, ','))
function and looking for a -1 result.  the string replace could be done by a function such as 
//replace commas with underscores
char * converttoCSVstring(char * s) {
    int i, l=strlen(s);
    for (i=0; i <= l; i++) {
        if (','==s[i]) {
            commareplacebuffer[i]='_';
        } else {
            commareplacebuffer[i]=s[i];
        }
    }
    return commareplacebuffer;
}

which need only return the pointer of a statically allocated or global buffer such as char commareplacebuffer[65500], since we are only going to export one string at a time, and the max C object size is 65536 bytes before a compile error.

with CSV format, it is simply necessary to output your fieldnames as a header, followed by the records.  you can make the header optional.
1. malloc a string char s[] that is large enough to handle all of the fields at once, plus a little extra for the commas and the null terminators.  
2. 
write out the field names separated by commas, followed by a newline.  this can be done with a single fprintf.  DATA: for every record: write out your fields' data with a single fprintf, calling converttoCSVstring() on the output of strings.
this only works if you have a single canned output format.
OR
If the fields are determined by boolean logic (vary depending on instance), make s empty, whatever fields are enabled, append/strcat the field name followed by a comma (use a temp string if you have to).  after all the field names are done, if s is not empty, remove the last comma off of the end of the s. fprintf s followed by a newline.
DATA:for every record, do the following: empty s again. whatever fields are enabled, append/strcat the field data (if it is a string, converttoCSVstring() it to s and strcat/append a comma to s. When all the fields are finished, if s is not empty, remove the last comma from the end of s. (after all, the comma is a separator, not a terminator, hence Comma-Seprated Values or CSV). fprintf s followed by a newline.

essentially what I have told you do to here is build up a string s with all the fields contatenated having commas after them.  zap any "last" comma, which makes the string CSV, then print it out.  when you do it this way, you can have any number of fields, and you get CSV format, and you can always go back and clean up the trailing comma and make it look nice. and with the string/text fields, all your violating commas get replaced with _ characters.

using double-quotes on strings is done by OpenOffice.org output, but makes no difference on import, and Excel does not use double-quotes on ouput (no matter on input): it is simply comma-separated and ends with cr+lf.  that may be best handled with using specific \r and what was the other character for linefeed?  long time.  what Excel chokes on with CSV, is when you have strings like +1-230-456-7890 it will try to calculate those (or is it that it only takes the -7890?) no matter how you try to format it: anything long-distance phone number is calculated as a generic number on import.

*** Bug 665668 has been marked as a duplicate of this bug. ***

I heartily agree: a CSV export capability is missing and is fundamental.

By the way, as a crude workaround for the lack of an export capability, you can run a Account Report in GnuCash, then select the transactions you want to export and use Edit->Copy to copy them as text.  You can then paste them into Gnumeric, for example.

CSV export is now in releas 2.6.  Can to test and report back here please?

Created attachment 270555 [details]
Testfile with account structure but no transactions

Created attachment 270556 [details]
csv file, exported from gnucash, to be imported into testfile (other attachement)

this file is to be imported into 'GnuCash Konten aus 2009 - Test.xml.gnucash'

Hi Mike,

sometimes it is necessary to split a file if it becomes too large. So i tried to export the transactions from 01.01.2012 up to now. It just simply did not work.

I use double-entry accounting and exported transactions within a certain time range of a gnucash account to a csv-file, tried to re-import it into another gnucash file with the same account structure and failed.

Tried this with different delimiters and field setups etc., but failed always. Also removed the negative sign from numbers, still did fail.

It would be very convenient, if gnucash could read it's own exported format while importing, so no format setup would be required. It also would be very handy, if a new gnucash file could be created on export, which just simply contains all accounts and the transactions within a selected time range.

The current bug report (bug 543287) is a request for a csv import/export feature. Such feature is available since GnuCash 2.6.0 and has seen several improvements since.

Helmut, the fact that noboby answered to your bug report is probably because it was attached to a feature request instead of reported in a separate bug.

I have created a separate bug report for your issue. Please follow up on bug 737193 with any other information. Thank you.

The feature request itself will now be closed.

GnuCash bug tracking has moved to a new Bugzilla host. This bug has been copied to https://bugs.gnucash.org/show_bug.cgi?id=543287. Please update any external references or bookmarks.