Разное форматирование @text(numberfield;"f2,") в контекстах

[Klido]

Есть NumberField соответствующего типа, 2 десятичных знака, разделитель тысяч. Всё норм.
Есть 2 вьюхи (одна сделана из второй).
Один из столбцов 1-й - как раз значение NumberField и формат столбца аналогичный.
Один из столбцов 2-й (ну или дополнительный тут же) вида @text(NumberField;"F2,").

Так вот глючит так:
- @text(@DbLookup(... занчениеNumberFieldизвьюхи1...);"F2,") показывает, к примеру, 1 414,40
- в столбце вьюхи2 видим неожиданно 1,414.40

Явно видимое значение поля 1414,4

что-то не так... перепроверил вьюхи и столбцы, ничего не понимаю... раньше таких разделителей не видел никогда в числовых преобразованиях
см. хелп и там есть
Use caution if using @Text to convert numbers or dates in a column. In databases hosted by a server, the numbers and dates always display using the format settings of the hosting server's operating system
но везде всё показывается вроде нормально и пр. Откуда замена разделителей, есть какие мысли? Не получается сложный ключ построить из-за этого...

 

[ToxaRat]

что-то не понял ва
1) в поле можно указать свой формат
2) в функции можно указать свой формат
3) в столбце можно указать свой формат

что не так?

 

[Klido]

не так видимый результат :blink:
все 1-3 варианта формата одинаковые, а отображение РАЗНОЕ, разные десятичный и тысячный разделители...
соответственно, делаю 2 текстовых ключа (текст от числа входит туда), но сравнить не могу, т.к. не совпадают...

пока туда-сюда, перепроверили локали на сервере, перегрузили даже линух - эффекта пока нет

 

[ToxaRat]

все 1-3 варианта формата одинаковые, а отображение РАЗНОЕ, разные десятичный и тысячный разделители...

там намертво указан формат или выбрано что системное? :blink:
учтите вид формирует сервер поэтому используется формат сервера - если не задано намертво
а в поле уже может быть формат клиента - так как просчитывается оно на клиенте(но в отдельных случайх может и на сервере)

 

[Klido]

там намертво указан формат или выбрано что системное?

всё очень просто...
в 1-м столбце вьюхи чиловое поле, офрмат столбца указан явно
во 2-м столбце то же @text(Field;"F2,"), столбец общего типа - и вот в нем видны неверные разделители...
а @text(@dblookup(Field);"F2,") по 1-му столбцу возвращает правильно....

Ну и сервер проверили на разделители, всё норм, да и в целом остальное всё работает без глюков...

 

[lmike]

если формат клиента и сервера не совпадают - так работать не будет (преобразованием к тексту)
придётся учитывать особенности локали клиента
с дробными намберами - тоже м.б. засада потому как в домине они хранятся не в фиксед формате (хотя ежели округлять одинаковыми методами - то должно работать)
можно искать вокэраунды (типа убирать национальное форматирование чисел)

 

[Klido]

если формат клиента и сервера не совпадают

на сервере правильные нац. форматы, клиентская ОС правильно настроена, в лотусине указано брать из ОС, есдинственно - и сервак и клиент у меня английские....

 

[lmike]

то что видим во вьюхе - клиент отображает намберы
то что делает сервер - зависит от локали
проверить - в скрипте запуска домины, вывести locale
у меня на сервере:
LANG=ru_RU.UTF-8
LC_CTYPE="ru_RU.UTF-8"
LC_NUMERIC="ru_RU.UTF-8"
LC_TIME="ru_RU.UTF-8"
LC_COLLATE="ru_RU.UTF-8"
LC_MONETARY="ru_RU.UTF-8"
LC_MESSAGES="ru_RU.UTF-8"
LC_PAPER="ru_RU.UTF-8"
LC_NAME="ru_RU.UTF-8"
LC_ADDRESS="ru_RU.UTF-8"
LC_TELEPHONE="ru_RU.UTF-8"
LC_MEASUREMENT="ru_RU.UTF-8"
LC_IDENTIFICATION="ru_RU.UTF-8"
LC_ALL=


можно и просто запустить locale (ежели скрипт запуска и энвиронменты, к-л, ничего не меняют)