[fpc-pascal] DBF Field name length and fpdbfexport

[Reinier Olislagers]

On 6-9-2011 8:32, Michael Van Canneyt wrote:
> On Tue, 6 Sep 2011, Reinier Olislagers wrote:
>> Wasn't aware of your/maintainers' preferences regarding naming, so I'll
>> keep that in mind. To be honest, just thought you guys were lazy & old
>> fashioned to use I & J as loop counter variables ;)
> 
> No, brevity is a virtue. Small is beautiful :-)
So size does matter - as I've been told before ;)

>> I've noticed that SQL insert statement output (issue 19937) and CSV
>> output (issue 19759) don't work well either (quoting issues for memo
>> fields and/or blobs), so if anyone's feeling in a bug fixing mood,
>> there's patches in there already ;)
> 
> I'll definitely have a look at them later today.
Thanks.

>> I do intend also to upload the dbf export test I used in these bug
>> reports for inclusion in the fcl db test directory.
> Great !
Done, issue 20163

>> 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.
< Feeling like I'm going to make obvious points, but well, I'm not
afraid of appearing obvious ;) >

I understand.
1. However, the existing csvexport code could be modified & moved to the
test suite to verify export. (Can't remember now if it already exists,
but we can also create a csvimport module for sdfdata and test the
export that way)
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.
The advantage would be that sdfdata gets more exposure, and, if needed,
another tool (LibreOffice, Excel, Access, .Net, C++ application) could
be used to read in & verify the "sdfdataexport" generated files.
After all, that's the final test, lacking a csv import module.

> You are aware that the Export components can be registered inside lazarus ?
Mmmm, yes, but I'm talking about having a nice shiny XMLXSDExport button
(a la existing SimpleXMLExport button) for people to throw on a form.
(Maybe that's what you mean, too...)
I had tried to create a button/component before but faild due to lack of
knowledge.
I now have the Lazarus book & more knowledge, so I'll give it another go.


>> Why, are you looking for people to improve Datadesktop (any hints) or
>> planning to improve it yoursel? ;)
> 
> I continuously improve it (slowly), and now your patches do as well, all
> these components are used in the data desktop :-) But from your
> descriptions I gathered that you were working on something similar as
> the data desktop.
Ok.
No, it's something else ;)

Though my holy grail that is (can be) data desktop related is having a
GUI/visual query builder such as those provided by Access, SQL Server
management studio (and presumably Oracle tools, have only tried them a
couple of times), and Business Intelligence tools.
That would allow technically inclined end users (or end users of
technical software ;) to construct their own queries, could be handy,
also in my current project.

Coffee first now, though ;)

Reinier