On Thu, 28 Jul 2011, Reinier Olislagers wrote:
On 27-7-2011 20:52, michael.vancann...@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.
_______________________________________________
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
