Enhancement request: 'Native' importing of '.CSV' files
Mike or Penny Novack
stepbystepfarm at mtdata.com
Wed Jan 21 09:05:15 EST 2009
I just want to point out what .cvs support entails for the benefit of
those for whom this isn't immediately obvious.
.cvs refers to the low level format of the data -- just that the file of
data consists of "records? delineated by <newline> and the records
consist of "fields" delineated by commas. But there is nothing defining
what data is in these fields and just as important, in what order.
That means that an "import from .cvs" functionality requires more than
just being able to accept data separated by commas. It needs a facility
where the user gets to enter information specifying which fields to be
included (and which possibly ignored) and in what order. That's the
substantial component of a project to "import from .cvs". Especially
since without a "guide" for the user on using* this "field specification
component" likely to be beyond the abilities of many "end users".
Michael D. Novack, FLMI
* keep in mind that it's not SIMPLY "using" (how to specify the skipping
fields and reordering fields. The "end user" is unlikely to know
(initially) what are the required fields and their order.
PS -- in it's simplest form, .cvs is an example of "positional;" rather
than "keyword" data. However it is entirely possible that "keyword" type
data could be stored in commas separated format (alternate fields are
"field identifier" followed by "field data"). If the data is of that
sort you don't need a field skipping and field reordering facility (a
program can use the field identifiers to determine the fields it wants
to put where regardless of order). However that isn't strictly speaking
"cvs. data" in spite of the way delineated by commas. In other words,
.cvs data and .cvs file don't mean EXACTLY the same thing.
More information about the gnucash-devel