Hi all,

I'd really like to use fields that contain carriage returns and line feeds in SDFDataset, so I've written a patch for SDFDataset as well as a test.

I'd appreciate it if someone could look at & hopefully implement http://bugs.freepascal.org/view.php?id=17285

This will help people that want to have better support for CSV export.

Note: I've seen in some other bug report, mailing list or forum (forget where), that some people say SDFDataset shouldn't support line endings in fields.
I've implemented a property called AllowMultiline in the patch; I'd be perfectly happy too if it is implemented but the property is not enabled by default.
(Also, the Lazarus book chapter 12.3 describes using SDFDataset for CSV files, so we can change either SDFDataset or the book contents ;)

Thanks!

BigChimp

PS: Shameless plug: Now working on fcl-db export to Unicode XML with XSD support for better interoperability with .Net (ADO.NET) and Microsoft Access...

I will look at the patch.

I will be glad to see your contribution :-)

Michael.

Michael Van Canneyt wrote

On Fri, 22 Jul 2011, Reinier Olislagers wrote:

<multiline entreaty>

I will look at the patch.

Dankjewel, Michael!

Doing fairly well with the export unit, it's just a massive PIA to implement datatype definitions for all possible field types.

Still, knowing not that much about XML (have avoided it, really), it was quite simple to follow the XML tutorial on the wiki and butcher the existing SimpleXML export unit into something that at least spits out XML data ;)

I think I'll have something by next week; I'll put up a patch when done.

After that, I might need some help on creating a Lazarus component for the export, but I'll get back to the list then.

Reinier
aka BigChimp (on the forum)

Michael Van Canneyt wrote

On Fri, 22 Jul 2011, Reinier Olislagers wrote:

<snip>

Michael & everyone else,

I've uploaded initial implementation in issue 19790. Can't get UTF8 working & would appreciate people having a look at it. (So my earlier estimate of having something by next week might still be valid ;)

Tested export using included test program; import worked in Access XP/2002. Other less important tests/things to do are included in bug report and source code.

If you guys can help me get UTF8 support working, and the code is approved by the devs, I think we can add this to FCL-DB ;)

Thanks,
BigChimp

TDOMDocument.CreateTextNode expects a DOMString which is WideString. The windows string to unicode conversion assumes the string is ansi. Use:

FOutputDoc.CreateTextNode(UTF8Decode(EF.Field.AsString));

BTW importing the output xml in access 2002 results in access crashing. I'm looking into that.

Ludo

On 23-7-2011 12:23, Ludo Brands wrote:
Hi Ludo,

Thanks for the help.

UTF8Decode would go from UTF8/Unicode to ANSI - but CreateTextNode expects UTF16? I don't get it.
RTFM for a change: ok, UTF8Decode decodes to a widestring (presumably UTF16 in Windows). I'll give it a go.

BTW importing the output xml in access 2002 results in access crashing. I'm looking into that.

Access XP SP3, 10.6771.6870 crashed for me too in earlier versions of the code. It worked for the code I uploaded.
Just tried it again with the test results output, and now it crashes for me, too...

I'll ask on an Access list to see if this is expected and what can be done...