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

[michael.vancanneyt at wisa.be]

On Thu, 28 Jul 2011, Reinier Olislagers wrote:

> 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?

Yes.

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

I don't think so, but I'm not sure. I would have to test that.

> 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 would appreciate that one. I think with some refactoring, the code could
be made much simpler.

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

Let me know when you're ready for a new patch :-)

Michael.