Sign in Join

Live chat for Free Pascal, Lazarus, Delphi and every Pascal programmer.

Mailing lists / fpc-pascal / 2011-07

RE : RE : RE : RE : Patch: new XML export for FCL-DB, was: SDFDataset multiline support: request for a look at patch+test, issue 17285

6 messages · 2 people ·

Reply by email Subscribe to this list Your subscription

Read-only archive. Use j and k to move between messages.

Ludo Brands

Don't know when it started, but at one point messages weren't going to the list anymore. Since my incoming messages are routed by title [fpc-pascal] they still showed up as coming from the list... Hence the confusion.

Show quoted text 7 lines
> The decimal point needs also to be localised ;( You are correct. I had explicitly left it as a . - must have taken a , for a . when tired. What a ridiculous idea, to generate different exports for the same data depending on what country you are in.

At one time, even VBA was localised. You couldn't run scripts created on a french excel on a german excel fe.

Show quoted text 6 lines
Actually, I might just leave it in US format as a . - this will at least fix the format and allow import by US/Anglophone countries. What do you think? (Better yet, I'll have a look at how newer versions of Access do this, maybe MS have fixed this since then)

DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it.

Show quoted text 5 lines
What's also strange is that currency fields don't have a currency symbol (e.g. €); I've got Dutch settings with . as thousands separator - no trace of a . in currency output. But it does output , as a decimal marker, not . Weird.

The currency sign and thousands separators is for display use only. I haven't seen any data format using them. Luckily, that is. The decimal separator is already confusing enough.

Ludo

Reply by email

Reinier Olislagers
to Ludo Brands
Ludo Brands wrote 10 lines
>> The decimal point needs also to be localised ;( > Actually, I might just leave it in US format as a . - this > will at least fix the format and allow import by > US/Anglophone countries. What do you think? (Better yet, I'll > have a look at how newer versions of Access do this, maybe MS > have fixed this since then) > DecimalSeparator is set to the system value in Sysutils and correspond to the machines localisation. You shouldn't hardcode it.

Well, I want to have the same output regardless of which locale you're in. (Unless there's a really good reason not to do that, or maybe, if there is a way to specify locale in the output XML) So then I should hardcode it, right? (I'm resetting them to their previous settings at the end of the module, but there might be a better way of doing that).

Or, quite probably, there's a better way to use FloaltToStr with a . without having to mess with DecimalSeparator. Had a quick look through the documentation but couldn't find anything obvious. Does anyone have any suggestions?

The currency sign and thousands separators is for display use only. I haven't seen any data format using them. Luckily, that is. The decimal separator is already confusing enough.

Yes, it does simplify things. But there might be a difference between 1 Zimbabwean dollar and 1 Swiss franc - both will display as 1 :(

Reply by email

Ludo Brands
to Reinier Olislagers
Show quoted text 10 lines
> DecimalSeparator is set to the system value in Sysutils and correspond > to the machines localisation. You shouldn't hardcode it. Well, I want to have the same output regardless of which locale you're in. (Unless there's a really good reason not to do that, or maybe, if there is a way to specify locale in the output XML) So then I should hardcode it, right? (I'm resetting them to their previous settings at the end of the module, but there might be a better way of doing that).

Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator.

Ludo

Reply by email

Reinier Olislagers
to Ludo Brands
Ludo Brands wrote 14 lines
>> DecimalSeparator is set to the system value in Sysutils and > correspond >> to the machines localisation. You shouldn't hardcode it. > Well, I want to have the same output regardless of which > locale you're in. (Unless there's a really good reason not to > do that, or maybe, if there is a way to specify locale in the > output XML) So then I should hardcode it, right? (I'm > resetting them to their previous settings at the end of the > module, but there might be a better way of doing that). > Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator. Ludo

I think we may misunderstand one another.

What I propose:
1. do NOT localize decimal separator in XML output, but keep US format . This has the advantage that export of the same data on any system will lead to the same results. (Disadvantage: Access might barf if a decimal , is suddenly a decimal .)

There are 2 more options:
2. Localize decimal separator according to OS locale settings such as Access XP is doing.
3. Follow the FormatSettings setting given in the GUI to determine output type.
(Or a combination of these)

In cases 1 and 3, I might need to customize the decimal separator for float export. This means (as far as I have been able to find out) tweaking the Sysutils.Formatsettings... Right?

In any event, I'll first try and see what newer versions of Access and ADO.NET do...

Reinier

Reply by email

Reinier Olislagers
to Ludo Brands: Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has…
Ludo Brands wrote 14 lines
>> DecimalSeparator is set to the system value in Sysutils and > correspond >> to the machines localisation. You shouldn't hardcode it. > Well, I want to have the same output regardless of which > locale you're in. (Unless there's a really good reason not to > do that, or maybe, if there is a way to specify locale in the > output XML) So then I should hardcode it, right? (I'm > resetting them to their previous settings at the end of the > module, but there might be a better way of doing that). > Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be used for this? It has a Property DecimalSeparator. Ludo

Ludo,

Maybe I misunderstood you: I have now chosen to use . unless the user overrides that in the export FormatSettings.
Would this be satisfactory?

Also, I've written and uploaded a small VB.Net test program to see the XML output .Net/ADO.NET creates/expects. The output is a bit different than Access XP, but might be quite near newer version of Access. I'm going to try and implement basic support for that.

Once I've finished that, I think it's done for now.

Thanks for the help,
Reinier

Reply by email

Ludo Brands
to Reinier Olislagers: I think we may misunderstand one another. What I propose: 1. do NOT localize decimal…
Show quoted text 19 lines
> Isn't property FormatSettings: TXMLXSDFormatSettings supposed to be > used for this? It has a Property DecimalSeparator. > > Ludo I think we may misunderstand one another. What I propose: 1. do NOT localize decimal separator in XML output, but keep US format . This has the advantage that export of the same data on any system will lead to the same results. (Disadvantage: Access might barf if a decimal , is suddenly a decimal .) There are 2 more options: 2. Localize decimal separator according to OS locale settings such as Access XP is doing. 3. Follow the FormatSettings setting given in the GUI to determine output type. (Or a combination of these)

OK let me more precise:

Change

  function TCustomXMLXSDExporter.CreateFormatSettings:
TCustomExportFormatSettings;

To

  function TCustomXMLXSDExporter.CreateFormatSettings:
TCustomExportFormatSettings;
  begin
    Result := TXMLXSDFormatSettings.Create(True);
  end;

This will initialise Formatsetting to sysutils format settings.

In procedure TCustomXMLXSDExporter.DoBeforeExecute;
  SysUtils.FormatSettings.DecimalSeparator :=
FormatSettings.DecimalSeparator;

This will give you option 2 if you don't change
TCustomXMLXSDExporter.FormatSettings and option 1 if you do override the settings. IMHO the default should be that the system that creates the file can also open it.

In cases 1 and 3, I might need to customize the decimal separator for float export. This means (as far as I have been able to find out) tweaking the Sysutils.Formatsettings... Right?

yes

In any event, I'll first try and see what newer versions of Access and ADO.NET do...

As you have probably already figured out, ADO.NET XML and Access 2002 XML aren't compatible. Files created by one can't be read by the other. ADO.NET breaks on the schemaname and suggest http://www.w3.org/2001/XMLSchema . Access can't read the table schema and imports everything as text.

Seems decimal separators are only a minor detail...

Ludo

Reply by email