Поведение, определенное ANSI, заключается в том, что любая операция, включающая null
, за исключением явного теста на недействительность (is [not] null
), дает значение null. К сожалению, поведение SQL Server по умолчанию нестандартно. Так...
Вы должны убедиться, что следующие два параметра включены для вашей хранимой процедуры или включены в вашем соединении, прежде чем выполнять автономный запрос:
set ansi_nulls on
set concat_nulls on
Если вы установите их в теле хранимой процедуры, настройки будут применяться только внутри этой хранимой процедуры; если вы установите их для соединения (путем выполнения инструкций set
), они будут одними для всех запросов, выполняемых для этого соединения (за исключением того, что хранимые процедуры имеют свой собственный контекст выполнения).
Жаль, что вы не можете гарантировать, что отсутствующие данные всегда будут null
, а не нулевой строкой (''
), это упрощает логику.
В любом случае, как только вы включите правильное поведение `null, что-то вроде
-- if missing data is always NULL, do this
select zip9 = t1.zip5 + coalesce( '-'+t1.zip4 , '' )
from someTable t1
or
-- if missing data might be nil ('') or NULL, do this
select zip9 = t1.zip5
+ coalesce(
'-'
+ case coalesce(t1.zip4,'') when '' then null else t1.zip4 end ,
''
)
from someTable t1
должен сделать трюк.
В противном случае, если вы не хотите включать правильное поведение, вы можете сделать что-то вроде этого. Это будет работать и со стандартным поведением NULL. Мне просто это не нравится, так как это включает в себя несколько тестов. Но TMTOWTDI, как говорится.
select zip9 = t1.zip5
+ case
when t1.zip4 = '' then ''
when t1.zip4 is null then ''
else '-' + t1.zip4
end
from someTable t1
person
Nicholas Carey
schedule
05.09.2012