Sascha Manns Ответов: 2

Как использовать convert с использованием case в SQL server?

У меня есть SQL-оператор (смотрите, что вы пробовали). Я хотел бы преобразовать Preis в nvarchar, прежде чем использовать этот случай.

Я попробовал это сделать с помощью

select Kategorie, modell, bezeichnung, convert(nvarchar(20),(preis),0) as Preis =
case
        when '{state:RepEuro}' != 'Smart Repair' then Preis
        else '140'
    end 
from tblminderwerte
where id = '{state:MinderwertSelect}'


Но это приводит к ошибке. Что было бы правильным путем?

Что я уже пробовал:

select Kategorie, modell, bezeichnung, Preis =
case
        when '{state:RepEuro}' != 'Smart Repair' then Preis
        else '140'
    end 
from tblminderwerte
where id = '{state:MinderwertSelect}'

MadMyche

Структура таблицы была бы хороша

2 Ответов

Рейтинг:
13

MadMyche

Значение, подлежащее преобразованию, является вторым элементом в операторе.
Для вашего экземпляра, похоже, существуют различные методы решения комбинации CASE & CONVERT
1. Вы можете поместить весь оператор case в качестве преобразуемого значения
2. Вы можете поместить преобразованное значение в качестве значения случая, требующего преобразования.

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

DECLARE @Temp TABLE (CaseEvaluation BIT, preis MONEY)

INSERT @temp 
VALUES (1, 123.45 ), (0, 543.21)

SELECT 
    Preis1 =
        CONVERT (
            NVARCHAR(20),
		    CASE
		        WHEN (CaseEvaluation = 1) THEN Preis
			    ELSE '140'
            END,
		  0
	   ),
    Preis2 =
        CASE
           WHEN (CaseEvaluation = 1) THEN  CONVERT (NVARCHAR(20), Preis, 0)
		   ELSE '140'
        END

FROM @Temp
--  Case   Preis1  Preis2
--  ------ ------  ------
--  True   123.45  123.45
--  False  140.00  140

Как бы то ни было, вы, вероятно, могли бы использовать CAST в этом случае.

Если этот запрос вызывается внешним приложением и он является числовым/денежным, я бы рекомендовал возвращать значения без преобразования, чтобы приложение могло легко работать с представленными значениями и обеспечить правильное региональное отображение.

Sascha Manns

Привет всем, большое вам спасибо за все решения и комментарии. В моем случае решение 2 от @MadMyche работает отлично. Большое спасибо :-)

MadMyche

Пожалуйста

Рейтинг:
1

OriginalGriff

Я совсем не уверен, что вы пытаетесь сделать там - ваше сравнение всегда будет успешным, потому что две строки никогда не будут совпадать.
Но если то что вы пытаетесь сделать это преобразовать числовое значение в NVARCHAR то это тривиально:

select Kategorie, modell, bezeichnung, 
    case
        when '{state:RepEuro}' != 'Smart Repair' then convert(nvarchar(20),(preis),0)
        else '140'
    end AS Preis
from tblminderwerte
where id = '{state:MinderwertSelect}'


Но я немного беспокоюсь, что вы показываете код из своего приложения, и происходит подстановка параметров, замена {state:RepEuro} с переменным содержимым в вашем приложении.
Если так, то не делай этого так! Никогда не объединяйте строки для построения команды SQL. Это оставляет вас широко открытыми для случайной или преднамеренной атаки SQL-инъекции, которая может уничтожить всю вашу базу данных. Вместо этого всегда используйте параметризованные запросы.

Когда вы объединяете строки, вы вызываете проблемы, потому что SQL получает такие команды, как:
SELECT * FROM MyTable WHERE StreetAddress = 'Baker's Wood'
Цитата, добавленная пользователем, завершает строку в том, что касается SQL, и вы получаете проблемы. Но могло быть и хуже. Если я приду и наберу вместо этого: "x';DROP TABLE MyTable;--", то SQL получит совсем другую команду:
SELECT * FROM MyTable WHERE StreetAddress = 'x';DROP TABLE MyTable;--'
Которые SQL видит как три отдельные команды:
SELECT * FROM MyTable WHERE StreetAddress = 'x';
Совершенно правильный выбор
DROP TABLE MyTable;
Вполне допустимая команда "удалить таблицу" 
--'
А все остальное-это комментарии.
Так оно и происходит: выбирает любые совпадающие строки, удаляет таблицу из базы данных и игнорирует все остальное.

Поэтому всегда используйте параметризованные запросы! Или будьте готовы часто восстанавливать свою БД из резервной копии. Вы ведь регулярно делаете резервные копии, не так ли?