Как избежать квадратных скобок в псевдониме столбца?
Следующее дает ошибку:
SELECT 1 AS [dada[daa]]
Msg 105, Level 15, State 1, Line 190 Unclosed quotation mark after the character string 'dada[daa] '.
Msg 102, Level 15, State 1, Line 190 Incorrect syntax near 'dada[daa] '.
и если у меня есть квадратные скобки в псевдониме столбца, я могу использовать такие кавычки:
SELECT 1 AS 'dada[daa]'
но я создаю несколько сложных динамических операторов T-SQL, и каждый псевдоним столбца заключен в квадратные скобки, а использование кавычек, если псевдоним содержит скобки, немного усложнит задачу.
Итак, есть ли способ как-то избежать этих скобок?
Ответы 2
Очевидным ответом было бы избегать квадратных скобок в именах. Скобки и двойные кавычки используются в качестве символов кавычек в T-SQL (двойные кавычки также используются в стандарте ANSI).
Кроме того, вы можете дважды заключать в кавычки символ кавычки, например:
select 1 as [da[da]]]
da[da]
------
1
Или
select 1 as "da[da]"
da[da]
------
1
И наконец
select 1 as "da""da"""
da"da"
------
1
Опять же, вы, вероятно, должны сделать это нет, так как это приводит к хрупкому коду.
Настоящая проблема
Из комментария кажется, что проблема действительный заключается в локализации имен полей для отображения. По какой-то причине это сделано в запросе, что может привести к различным проблемам, если имя поля содержит кавычки или другие непредвиденные символы.
Обычное решение этой проблемы — локализовать результаты на уровне презентация, а не в запросе. Это поддерживается большинством инструментов отчетности, стеков веб-приложений и настольных приложений. Windows Forms, WPF и все стеки ASP.NET имеют свои собственные функции локализации.
Так же как и Службы отчетности, хотя более современное решение будет извлекать переводы из другого источника, например из базы данных.
@gotqn Пока псевдонимы полей установлены в запрос, кавычки будут проблемой, независимо от базы данных. Лучшим (и более распространенным) решением будет локализация имен полей в интерфейс, например, веб-страницы, формы или инструмента отчетности. Это поддерживается большинством веб-стеков и инструментов отчетности.
@gotqn, если вам нужно локализовать псевдонимы в запросе, вам нужно проверить псевдоним, чтобы увидеть, какая цитата в нем содержится, и использовать «другой». Например, в MySQL вы можете проверить ` или " и заключить псевдоним в другую кавычку. В SQL Server это [] или ". В PostgreSQL есть строки в долларовых кавычках. Если псевдоним содержит кавычки обе .... не позволяйте им введите обе кавычки.
Вам нужно удвоить их, как одинарную кавычку ('):
SELECT *
FROM [My]]Table];
Вам нужно сделать это только с правыми скобками, хотя левые не должны быть. Например:
SELECT *
FROM [My[Table];
Однако, основываясь на этом утверждении «но я создаю некоторые сложные динамические операторы T-SQL, и каждый псевдоним столбца заключен в квадратные скобки, и использование кавычек, если псевдоним содержит скобки, немного усложнит задачу»., кажется, что вы делаете что-то вроде '... FROM [' + @TableName + '] ...'; Не надо. Используйте QUOTENAME: '... FROM ' + QUOTENAME(@TableName) + '...'.
QUOTENAME правильно заключает в кавычки и экранирует вашу переменную. Таким образом, для значения '[MyTable]' будет возвращено '[[MyTable]]]'. У него также есть второй, необязательный параметр, который можно использовать для цитирования входных строк с другими идентификаторами. Например, предположим, что переменная @String имеет значение «Не делать», QUOTENAME(@String, '''') вернет 'Don''t'.
спасибо, чувак - удвоить последнее было достаточно - это только для псевдонима столбца, без источников данных, так что все в порядке.
Если вы можете, я предлагаю QUOTENAME @gotqn. Это бесценно при создании динамического SQL.
В идеальном мире - это будет хорошо :-) Я нахожусь в ситуации, когда клиентам разрешено использовать глобализацию для каждого псевдонима столбца, чтобы получить собственный текст в своих отчетах, и никаких ограничений в интерфейсе глобализации не установлено...