Is it possible to use an invariant culture to pass data using XML

Author: (mmontealegre)

We have a project where we are passing data to a reporting tool using XML. Currently our code sets the $nlslocale and does an xml save, like so $nlslocale = var_sNLSLocale xmlsave var_sFastReportXml, "DTD:DTDFROSCH.CMDSERIES" If you examine the variable you will see date/time fields are different if you change your nsllocale between US, Italian, Dutch, Finnish.  Our problem is for Finnish in particular, although I suspect some other European countries might have similar problems. In Finnish the date looks like such (notice the periods in the time)   <START_TIME.SCHD.CMDSERIES>27.3.2015 10.00.00</START_TIME.SCHD.CMDSERIES> According to windows it should be hh:mm:ss.  So on the reports side it reads the windows setting and using C# code the ParseDate function will fail.  According to Wikipedia, The 12-hour clock is used in the spoken language and idiomatic expressions. The 24-hour notation is used in writing, with a period as the standardized and recommended separator (e.g. “15.07” or “8.27”). However, colon is almost exclusively used instead of period in computing environments. The conventions are the same for Finnish and Swedish.  Anyways I have two questions 1) Why is Uniface different than the windows setting?  Is there some other library they use to determine these date formats. 2) What is the proper way to be doing this?  In .net environments they expect you to use the CultureInfo.InvariantCulture to pass data around between two programs.  You would still of course display the data in the proper culture format but passing it back and forth using XML should be in a generic format. 


  1. Hello, In case you are passing XML data to an external tool then it might be a better solution to use Structs. The structToXml statement will convert Uniface date/time values to XML date/time values - and the statement xmlToStruct can convert date/time values the other way. When using xmlsave/xmlload then date/time values are saved/loaded using the field layout of the specific date/time field. The statements xmlsave/xmlload are actually more intended for exchanging XML data between Uniface components (and not really for exchanging data with non-Uniface components). And please note that since Uniface 9.6.06 (Maintenance Pack MX05) it also is possible to use Structs for Disconnected Record Sets - something that was before only possible when using xmlsave/xmlload. Hope this helps. And if you require any further information, let me know. Daniel

    Author: diseli (
  2. I am indeed passing via XML to an external code.  The external tool is called Fast Reports and it has .Net (C#) code on it's side.

    Author: mmontealegre (
  3. Thanks for your reply though.   I suppose one solution I can use it to paint every date/time field on the service that sends this info and use a template layout where I can define how the dates look.  The entity model does not define these and I cannot change that, so this is not the best solution in the world because we will have multiple forms for different reports, but at least it works.  If anyone else has a different idea let me know

    Author: mmontealegre (
  4. You are welcome. Although I'm not really sure if it'll be possible to get the desired layout by using a date/time layout. Okay, it might work for date or time only fields. When it comes to DateTime fields that's a bit more tricky. An XML DateTime is specified in the following form "YYYY-MM-DDThh:mm:ss", where T indicates the start of the required time section. But 'T' is used by Uniface as a time display format for Ticks (1/100 seconds) - and it (currently) is not possible (AFAIK) to include the letter T in the layout of DateTime field. You would need to copy the value of a DateTime field to a string field, format it accordingly and then save it to the XML stream (using xmlsave). When using Structs you don't need to do such an extra data conversion step. Okay, one prerequisite is that you are using either Uniface version 9.5 or 9.6 - and in case you would like to use disconnected records then you need at least version 9.6.06. If I find the time then I'll try to create a small sample that demonstrates how Structs could be used to create an XML file (instead of xmlsave). Would this be something that would be useful for you? Hope this helps. Daniel

    Author: diseli (
  5. Fast Reports reads in a data source, which in this case is an xml file generated from Uniface.  I don't think that Fast Reports can read the Structs directly.  It did give me an idea to go from entity->struct->xml clear/e "schd" retrieve/e "schd" setocc "schd", 1 componentToStruct $1 "schd" structToXml $2, $1 This gives the generic format in the xml like such   <START_TIME>2008-05-17T07:30:00.00</START_TIME> This may be some help, although it loses some of the XML structure, such as the table name in the XML tag.

    Author: mmontealegre (
  6. Hi, At worst, you could try UXMLWRITER, it's less easy than XMLSAVE, but you could find other benefits like use attributes, namespaces , no dtd etc ...

    Author: Gilles (
  7. mmontealegre said I don't think that Fast Reports can read the Structs directly.

    No, that is correct. A Struct is an object that only exists in the memory of Uniface. You need to use a Proc statement (such as structToXml) to convert the Struct to a data format that could be used outside of Uniface.

    mmontealegre said It did give me an idea to go from entity->struct->xml

    Good. That is actually what I've tried to suggest in my last post.

    mmontealegre said This may be some help, although it loses some of the XML structure, such as the table name in the XML tag.

    What exactly do you mean? Do you mean the XML elements that include the field data? If you need "fully qualified" field names then you always could change the name of the specific Struct members (before converting it to XML). But do you really need the full names? The reason why xmlsave is generating these names has to do with the fact that Uniface requires the info for reconnecting the data. From an XML point of view this is not necessary. And if required, you also could add additional attributes, namespaces, etc. to the Struct. The Uniface Library includes a couple of samples that (as far as I remember) demonstrate this. Hope this helps. Daniel

    Author: diseli (