> So you're saying that this:
> 2011-07-22T15:00:00+02:00
> can be simplified to this: 2011-07-22T15:00:00
> ?
> I'll amend my simple ADO.Net test program to import XML and
> see what it does.
>
> If that is true, it would save a huge amount of aggravation.
>
It does. It uses TZ to convert if specified but assumes local time if not
specified. Tested this when importing access 2010 data.
> Still, I'd rather have an exporter that loses the least amount of data
> possible: if it can tell it's GMT/UTC+2, it would be nice if
> the export field could be annotated with whatever timezone
> info I can come up with. Could even be a comment in the XML file...
>
> > In the same line, trying to match the output of the
> different access
> > versions and ADO.NET's isn't, IMHO, the correct approach
> neither. The
> > goal for an exporter should be to create XML files that can be
> > imported correctly and nothing more. I just tested access
> 2010 and the
> > XML output created by TCustomXMLXSDExporter was just imported fine,
> > except for the decimal point that needed to be a dot. MS
> has learned
> > in the mean time ;) On the other hand, if you look at the
> XML output
> > from 2010, it is completely different from all seen before (see
> > attached file, exported from your test.mdb).
> Thanks for the tests.
>
> What I have been trying to do all along is to find the
> biggest common denominator of XML files. As it turns out and
> you mentioned, there's differences between ADO.Net and (one
> or more versions of) Access. IIRC, Access XP was the first
> version to have XML import/export functionality. I know that
> Access XP is finicky in its XML support, but that's what I
> have and I'd like support for it ;) If 2010 imports the XP
> stuff fine, probably 2007 and 2003 will, too. But it would be
> nice if that could be confirmed by tests. As I wasn't sure
> that Microsoft was able to be backward compatible, so I
> hedged my bets by keeping open the possibility of more modes...
>
> Now I'll probably end up with one single Access version. If
> newer versions have problems with the XP version, I'll just
> have to add more modes, though.
>
> I don't completely agree with you that an exporter should
> just create XML files readable for the target application.
> The contents/meaning of the imported data must not differ
> from the contents/meaning of the original data as far as possible.
>
I think you misunderstood me. All the schema information available should be
specified correctly in the XML file. What is not relevant, IMHO, is the
format in which it is presented as long it is correctly and fully
interpreted by the importer. So if the access 2002 format you created fits
the bill, then that should be sufficient. There are for example a lot of
presentation type of atttributes added in access 2010 (display width,
locale, etc) which are not part of the real data schema. No reason to
emulate (invent) these properties for our purpose.
> > Regarding ADO.NET, different tests and googling show that its XML
> > reader is simply not compatible with MS ACCESS XSD (all versions).
> ...
> > I would conclude that exporting for ADO.NET and access are
> 2 different
> > paths.
> I originally suspected MS might have wised up and would make
> a newer version of Access interoperable with ADO.Net.
> Obviously they haven't.
>
> I'm splitting the code into Access and ADO.Net parts. The
> structure of the documents is similar: metadata followed by
> actual data, it's just a matter of getting the right elements
> etc in there.
>
> When I'm done, I can have a look at Excel and see if it can
> read either format. If not, I'll just have to add another ;)
>
> Finally, thanks for all the suggestions and tests, Ludo, I
> appreciate it.
You're welcome.
Ludo
PS attached the XSD as exported by Visual Studio 2008 from test.mdb.
testDataSet.xsd
Description: XML document
___
fpc-pascal maillist - fpc-pascal@lists.freepascal.org
http://lists.freepascal.org/mailman/listinfo/fpc-pascal
