Триггер, неправильно выполняется условие

[Prizrak86]

Есть таблица

в ней по [код_статуса_брони] остаются те помещения, которые заняты в текущий момент (код 1 и 2).

запрос для этого

SELECT *
FROM [dbo].[Бронирование_помещения] as бронь
Where (бронь.Код_статуса_брони = 1 or бронь.Код_статуса_брони = 2)

результат запроса


пишу триггер событие добавление записи

create trigger ProverkaSvobodnNomerov_12
on [dbo].[Бронирование_помещения]
for insert
as

 if (
	(SELECT 
		COUNT(*) 
	FROM 
		[dbo].[Бронирование_помещения] as бронь, 
		inserted
	WHere 
		(бронь.Код_статуса_брони = 1 or бронь.Код_статуса_брони = 2) and 
		бронь.Код_помещения = inserted.Код_помещения) > 0) 
Begin
	RAISERROR ('номер уже занят другим гостем', 16, 10)
end

при этом я сравниваю [Код_помещения] и вывожу количество записей в условие, логика такова, если будут записи в результате этого запроса, значит это помещение забронировано и тогда выводиться сообщение, но на деле это сообщение выводится всегда, что не так?

[Streletz]

Логика такова, что этот запрос

Сообщение от Prizrak86

SELECT 
		COUNT(*) 
	FROM 
		[dbo].[Бронирование_помещения] as бронь, 
		inserted
	WHere 
		(бронь.Код_статуса_брони = 1 or бронь.Код_статуса_брони = 2) and 
		бронь.Код_помещения = inserted.Код_помещения

всегда будет возвращать больше 0. Почему? Читайте о том, что из себя представляет таблица inserted.
Создайте хранимую процедуру для добавления и в ней, перед тем как непосредственно добавить запись, выполняйте проверку. Либо используйте триггеры instead of.

[Prizrak86]

Спасибо. Я понял почему она выдает результат больше нуля. Но как получить запись которая добавляется?

Сообщение от Streletz

Логика такова, что этот запрос
всегда будет возвращать больше 0. Почему? Читайте о том, что из себя представляет таблица inserted.
Создайте хранимую процедуру для добавления и в ней, перед тем как непосредственно добавить запись, выполняйте проверку. Либо используйте триггеры instead of.

Цитата из статьи на которую вы мне указали.

В таблице inserted находятся копии строк, с которыми работали инструкции INSERT или UPDATE. При выполнении транзакции вставки или обновления происходит одновременное добавление строк в таблицу триггера и в таблицу inserted.Строки таблицы inserted являются копиями новых строк таблицы триггера.

Прочитал Ваши ссылки, здесь написано что в таблице inserted содержаться добавляемые строки, а по ходу работы получается что в ней содержится вся копия таблицы. Так что в ней содержится и как мне получить ту единственную запись, которая будет добавлена в таблицу???

[Аватар]

Там не копия, а временная таблица именно с добавляемыми записями. И триггер отрабатывает после вставки. Т.е. вставляемые записи уже есть в таблице и их нужно исключить во WHERE. И отката транзакции в упор не вижу. Да, и наверно лучше триггер instead of

[phomm]

Как-то плоховато у Вас с теорией, автор.
Да и с проектированием.

Вот что такое по логике проверка свободных номеров - это выдача инфы ресепшенисту или заезжающему о количестве и ассортименте доступных для съёма номеров. При чём тут проверка _вставки_ ?

Во-вторых, недопущение ошибочных данных с т.з. бизнес-логики, а в этой задаче - занятие уже занятого номера, обычно перекладывают на плечи автоматики, а не пишут свой код, т.е. это декларативная постановка, а не императивная. В терминах реляционной модели для этого используются ключи, в данном случае мог бы подойти уникальный ключ на поле Код_помещения и на нечто, отражающее занятость номера. Вот как выразить последнюю, ввиду того, что там 2 разных кода - не знаю.. наверное через вычисляемое поле как-то можно.

Если же писать код, то лучше писать ХП, а не триггер, триггеры вообще редко стоит применять, ибо они легко могут давать сложности. А про триггеры конечно ещё почитать стоит.

Ну и общего плана замечания - имхо,некрасиво, что в базе поля на русском.
Ну и COUNT(*) - плохая практика, указывайте одно какое-то поле, обычно первичный ключ, т.к. * не всегда сервер разрулит это в оптимизацию, думаю.

[Prizrak86]

Сообщение от phomm

Как-то плоховато у Вас с теорией, автор.
Да и с проектированием.

Вот что такое по логике проверка свободных номеров - это выдача инфы ресепшенисту или заезжающему о количестве и ассортименте доступных для съёма номеров. При чём тут проверка _вставки_ ?

Во-вторых, недопущение ошибочных данных с т.з. бизнес-логики, а в этой задаче - занятие уже занятого номера, обычно перекладывают на плечи автоматики, а не пишут свой код, т.е. это декларативная постановка, а не императивная. В терминах реляционной модели для этого используются ключи, в данном случае мог бы подойти уникальный ключ на поле Код_помещения и на нечто, отражающее занятость номера. Вот как выразить последнюю, ввиду того, что там 2 разных кода - не знаю.. наверное через вычисляемое поле как-то можно.

Если же писать код, то лучше писать ХП, а не триггер, триггеры вообще редко стоит применять, ибо они легко могут давать сложности. А про триггеры конечно ещё почитать стоит.

Ну и общего плана замечания - имхо,некрасиво, что в базе поля на русском.
Ну и COUNT(*) - плохая практика, указывайте одно какое-то поле, обычно первичный ключ, т.к. * не всегда сервер разрулит это в оптимизацию, думаю.

Спасибо за конструктивную критику. Я поговорю об этом с преподавателем.