CSVExport: was Re: [fpc-pascal] DBF Field name length and fpdbfexport

[Reinier Olislagers]

On 6-9-2011 9:14, Reinier Olislagers wrote:
> On 6-9-2011 8:32, Michael Van Canneyt wrote:
>> On Tue, 6 Sep 2011, Reinier Olislagers wrote:
>>> Also, creating a Lazarus XMLSDExport component, and possibly
>>> rewriting CSVexport to use sdfdata, so it needs less code
>>> (current code basically duplicates what sdfdata does...)
>> Well, the reason I didn't do that was that I wanted to test the
>> generated files with sdfdata. Kind of a cross-check.

Just thought of some more reasons - I'll be away for some days, so I
thought I'd throw it out to the list to ponder.
(Reworded previous reasons for - hopefully - coherent argument):

<Feeling like I'm making obvious points, but well, I'm not afraid of
appearing obvious ;)>

I understand, but:

1. An import test could be written using TStringList.LoadFromFile.
This will probably work for simpler formats. Will probably need a fix in
TStringList.DelimitedText (issue 19610)
Hint: Dataset.LoadFromFile data import functionality for FCL ;)

2. Alternatively, we could use a comprehensive but fairly static (i.e.
test code/data doesn't change often) export test. That would include the
generated CSV data as data. Then let the test compare the
"sdfdataexport" generated file with the stored CSV data.

3. Additionally, if needed, another tool (LibreOffice, Excel, Access,
.Net, C++ application) could be used to read in & verify the
"sdfdataexport" generated files.

4. Using sdfdataset, you get multiline capability (embedding a line
break in a field) for free (mantis 17285) ;)

The advantage of moving to sdfdataset would be code simplification/reuse
Sdfdata also gets more exposure and therefore testing.


And, yes, I'm willing to write up a patch for review, but probably not
soon...

Thanks,
Reinier