nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

decimal separator identify/query

HugoAhlenius

Hi, I am working on a web application, and the server is ArcGIS 10.1.

Now I just noticed something very funny - when I do query tasks everything works as it should, but for an identify task, the server returns comma as the decimal separator. The server is located in Norway, and I haven't investigated it further (and experimented) but it is likely that the user account that the server is running under is set to Norwegian regional settings. Setting the user to en-us probably fixes this...

I did some troubleshooting, and I could see the comma-decimal separator in the requests - see the json returned from this query for instance: http://bit.ly/Sxbynh. Note the shape.area attribute/field for instance.

Vind meer berichten getagd met

Accepted answers

All comments

__Rich_

Too bad it is convoluted for me to log a bug (I would have to do it through my national reseller, and then it doesn't feel worth it). I was hoping that someone from the mothership would post in the thread...

I have an issue logged with Support concerning the inconsistency in date format from the REST methods - will post if I hear anything back...although I raised it nearly 2 months ago and it's been logged in Nimbus for 1 month so I'm not too hopeful of an answer.

Also, since it's server-side, you may get a more 'direct line' to the appropriate ESRI people via http://forums.arcgis.com/forums/11-ArcGIS-Server-(10.0-and-prior)-REST-API

HugoAhlenius

Too bad it is convoluted for me to log a bug (I would have to do it through my national reseller, and then it doesn't feel worth it). I was hoping that someone from the mothership would post in the thread...

__Rich_

So MSSQL had nothing to do with the thing

Just to be clear, I wasn't implying that the locale of the DBMS was definitely affecting your results, just that it does have an effect in some circumstances. (e.g. can depend on the settings/functionality of the client library used to connect to the DBMS)

Glad you've found a workaround for your issue, let's hope that ESRI can 'align' the various REST methods to be consistant in how they return data. 🙂

HugoAhlenius

It was as I thought - I changed the regional settings of the arcgis account on the server, and then the request looks as I expected it. So MSSQL had nothing to do with the thing, nor the locale setting on the client (as obvious in the REST request). The URL in the first post is no longer relevant, that shows the expected decimal separator now.

__Rich_

SQL Server is not sensitive to the regional settings.

Are you applying that statement to all of SQL Server?

HugoAhlenius

What locale is SQL Server using?

It is irrelevant, SQL Server is not sensitive to the regional settings. One can set the collation per database/table/field, but that is primarily the sort order. Dates and numerical values are stored in binary format.

Which do you think is behaving correctly?

The query, since dojo/the javascript API does not apply the browser/locale settings in the identify case, and the attribute is interpreted as a string.

__Rich_

Another aspect that tells me that this is a bug - the key here seems to be the locale the user account on the server runs under, not anything related to by data store/repository...

What locale is SQL Server using?

Which do you think is behaving correctly?

Identify i.e. locale-aware)
Query i.e. forced to (probably) en-US

I know which you prefer, but that's not the same question 😉

The biggest issue I have is that they behave differently! (must be considered a bug)

HugoAhlenius

Another aspect that tells me that this is a bug - the key here seems to be the locale the user account on the server runs under, not anything related to by data store/repository...

__Rich_

Conversion to a universally acceptable (!) locale initially seems an attractive option, but I think the service stating the locale is probably (possibly?) a more robust approach based on approx 15 seconds of thinking! (no doubt I haven't thought this through and someone will tell me it's a terrible idea!)

...and on top of locale you've also got format e.g. date. (a locale may not guarantee a single format for the type)

HugoAhlenius

🙂

Thanks for the response by the way! Think thing with JSON and the REST api - since it doesn't specify the format of values (strings, double etc) and it is human readable - it is a bit deceiving. But for it to work with a variety of clients, it either needs to specify the format, or hold it in a predictable format (e.g. en-us).

The json response shouldn't be for human consumption anyways, and the values should be cast to a suitable locale in the presentation layer!

__Rich_

The data store (in SQL Server / enterprise geodatabase), stores numbers in binary format anyways.

But you don't directly read the internal value representations of the DBMS and neither do the tools you mentioned.

Anyway, yes there should be consistency across the responses from the REST methods, that is an issue
---------------
On a separate matter, I'm not sure I agree with ESRI forcing your data values into any locale, it could be argued that since you're the custodian of those data values, you should ensure a consistent locale. Aside from the REST bug (and I agree it's a bug) they are effectively delegating responsibility for locale selection to the people who are based place to chose i.e. the owners of the data.

HugoAhlenius

The responses, of course... The data store (in SQL Server / enterprise geodatabase), stores numbers in binary format anyways. I can inspect the attributes in the data store (using ArcCatalog, or SQL Server tools), and see that decimal separator work as expected.

The data should be queried and communicated behind the scenes in a common format (e.g. en-us) and presented to the user according to overrides (i.e. dojo.locale).

What leads me to call this a bug is that a queryTask work as expected, while an identifyTask doesn't...

__Rich_

...I could see the comma-decimal separator in the requests...

Do you mean in the responses?

If the server processes are running under Bokmål then I'd expect dates, numbers etc in attributes to be expressed in that locale e.g. do you know how the underlying data store is configured? Do you know who else uses the data? (probably people in Norway for a start!)

ESRI may have chosen to 'normalise' 'system' values for functional purposes into a chosen locale (probably en-us) but it'd be dangerous for them to start messing with proprietary values that they do not 'own'.

Having said all that....I think all the tasks should be consistent in what they do to values - this isn't the only thing that is done differently between the task types e.g. date format.

HugoAhlenius

To me it seems like a bug!

Doe mee aan het gesprek

Aangemelde leden kunnen berichten plaatsen, updates volgen en meer. Nieuw hier? Registreer een gratis account.

Snelle Links

Community Help
Find useful guides, FAQs, and documents to help you navigate and make the most of Esri Community.