[fpc-pascal] Patch: new XML export for FCL-DB ready for inclusion, issue 19790 - includes Delphi Clientdataset

Reinier Olislagers reinierolislagers at gmail.com
Thu Jul 28 06:41:38 CEST 2011


On 27-7-2011 20:52, michael.vancanneyt at wisa.be wrote:
> 
> 
> On Wed, 27 Jul 2011, Reinier Olislagers wrote:
> 
>> Update: includes first stab at Delphi Clientdataset. Please test with
>> various datatypes as I haven't been able to map all of them...
> 
> I added your implementation to SVN.
Thanks, Michael.

I noticed your remark on a failing conversion of a longint to a string -
that code wouldn't have worked. Obviously a priority to increase the
test coverage.
> 
> But you may want to check your implementation on 64-bit prior to
> submitting.
I will compile & test on Linux x64 before submitting an upgrade
> 
> Code like
> 
>       ftWideString: //fixed length or at least max length string
>       begin
>         TDOMElement(ColumnNode).SetAttribute('fieldtype', 'string');
>         TDOMElement(ColumnNode).SetAttribute('WIDTH',
>           UTF8Decode(string(ExportFields.Fields[ItemCounter].Field.Size)));
>       end;
> 
> Is dead wrong. It passes on 32-bit (but generating wrong data), but
> fails to compile on 64-bit.
Hmmm, hadn't thought about size.  (And size obviously matters here ;)

Just to make sure I understand correctly: in a string field, Field.Size
indicates the number of characters that can be stored in a field, while
Field.DataSize indicates the number of bytes, right?

Complication is that e.g. Access expect character size for their size
specification. Delphi Clientdataset will probably require datasize.

Thanks, I'll look into it.
> 
> The compiler has a warning for this, so checking your warnings while
> compiling for 32-bit may also be a good idea.
> 
> Michael.

New plans:
1. Expand test coverage: additional datatypes, fixed string width fully
filled with East Asian characters.
Use the output of this coverage as baseline to verify code commits still
deliver the proper export.
2. Incorporate fixes, e.g. those mentioned by Ludo Brands. Please keep
those reports coming ;)
3. Clean up code (needless class-level variables), look into possibility
of splitting entire procedures according to export format, instead of
multiple case...of statements inside a procedure body.

I'll keep a Mercurial repository on bitbucket to coordinate with others
and upload a new patch when done.

Thanks,
Reinier



More information about the fpc-pascal mailing list