SQL Server: какую локаль следует использовать для форматирования числовых значений в формат SQL Server? - PullRequest
2 голосов
/ 23 марта 2010

Кажется, что SQL Server не принимает числа, отформатированные с использованием какой-либо конкретной локали. Он также не поддерживает локали с цифрами, отличными от 0-9 .

Например, если текущим языковым стандартом является бенгальский, то число 123456789 будет выглядеть как "১২৩৪৫৬৭৮৯" . И это только цифры, не важно, какой будет группировка цифр.

Но та же проблема возникает для чисел в инварианте , который форматирует числа как «123 456 789», которые SQL Server не принимает.

Существует ли культура, которая соответствует тому, что SQL Server принимает для числовых значений? Или мне придется создать какую-то собственную культуру "sql server", самостоятельно генерируя правила для этой культуры из процедур форматирования более низкого уровня?

Если бы я был в .NET (а я нет), я мог бы просмотреть строки Standard Numeric Format . Из кодов формата, доступных в .NET:

  • с (Валюта): $ 123,46
  • д (десятичное число): 1234
  • e (экспоненциальная): 1.052033E + 003
  • f (Фиксированная точка): 1234.57
  • г (общее): 123,456
  • n (Число): 1 234,57
  • p (в процентах): 100,00%
  • r (туда и обратно): 123456789.12345678
  • x (шестнадцатеричный): FF

Только 6 принимают все числовые типы:

  • c (Валюта): $ 123,46
  • d (десятичное число): 1234
  • е (экспоненциально): 1.052033E + 003
  • f (Фиксированная точка): 1234.57
  • г (общее): 123,456
  • n (Число): 1234,57
  • р (проценты): 100,00%
  • r (в оба конца): 123456789.12345678
  • x (шестнадцатеричный): FF

И из этих только 2 генерируются строковые представления, в любом случае в en-US , которые будут приняты SQL Server:

  • c (Валюта): $ 123,46
  • d (десятичное число): 1234
  • e (Экспоненциальная): 1,052033E + 003
  • f (Фиксированная точка): 1234.57
  • г (общее): 123,456
  • n (Число): 1 234,57
  • p (в процентах): 100,00%
  • r (в оба конца): 123456789.12345678
  • x (шестнадцатеричный): FF

Из оставшихся двух фиксированное значение зависит от цифр языкового стандарта, а не от используемого номера, оставляя Общий формат g :

  • c (Валюта): $ 123,46
  • д (десятичное число): 1234
  • е (экспоненциально): 1,052033E + 003
  • f (Фиксированная точка): 1234,57
  • г (общее): 123,456
  • n (Число): 1 234,57
  • p (в процентах): 100,00%
  • r (в оба конца): 123456789.12345678
  • x (шестнадцатеричный): FF

И я даже не могу с уверенностью сказать, что формат g не добавит группировку цифр (например, 1234).

Существует ли локаль, которая форматирует числа так, как ожидает SQL Server? Есть ли код формата .NET? Код в формате Java? Код в формате Delphi? Код формата VB? Код формата stdio?

латино-позици цифр

1 Ответ

3 голосов
/ 23 марта 2010

Спецификации SQL Server для констант описывают допустимые форматы в выражениях и пакетах T-SQL:

целое число константы представлены строкой чисел, которые не являются заключены в кавычки и не содержат десятичные точки. целое число константы должны быть целыми числами; Oни не может содержать десятичные дроби.

десятичные константы представлены строкой чисел, которые не являются заключенные в кавычки и содержит десятичную точку.

float и real константы представлены с использованием научных нотации.

money константы представлены в виде строки чисел с необязательным десятичная точка и необязательная валюта символ в качестве префикса. Денежные константы не заключены в кавычки. SQL Сервер не обеспечивает какой-либо правила группировки, такие как вставка запятая (,) каждые три цифры в Строки, которые представляют деньги. Запятые игнорируются в любом месте указанного буквальный перевод денег.

Чтобы указать, является ли число положительным или отрицательным , примените одинарные операторы + или - к числовой константе. Это создает числовое выражение, которое представляет числовое значение со знаком. Числовые константы используют положительные значения, когда унарные операторы + или - не применяются.

Хорошей новостью является то, что клиентским приложениям не нужно беспокоиться об этих требованиях. Клиентские приложения должны передавать числовые значения как @ parameters , а не как литеральные константы T-SQL.

...