Указатель NULL
- это тот, который указывает на никуда. Когда вы разыскиваете указатель p
, вы говорите «дайте мне данные в месте, хранящемся в« p ». Когда p
является нулевым указателем, местоположение, хранящееся в p
, является nowhere
, вы говорите «Дайте мне данные в месте« нигде ». Очевидно, он не может этого сделать, поэтому он выбрасывает NULL pointer exception
.
В общем, это потому, что что-то не было правильно инициализировано.
Я просто видел эту статью, недавно выделенную на SQL Server Центральная новостная рассылка, и это, кажется, предлагает способ, которым можно найти полезное использование Context_Info на соединении:
http://www.mssqltips.com/tip.asp?tip=1591
<час>РЕДАКТИРОВАНИЕ Водяной черепахой:
вышеупомянутая ссылка включает следующий код:
USE AdventureWorks;
GO
-- creating the table in AdventureWorks database
IF OBJECT_ID('dbo.Table1') IS NOT NULL
DROP TABLE dbo.Table1
GO
CREATE TABLE dbo.Table1(ID INT)
GO
-- Creating a trigger
CREATE TRIGGER TR_Test ON dbo.Table1 FOR INSERT,UPDATE,DELETE
AS
DECLARE @Cinfo VARBINARY(128)
SELECT @Cinfo = Context_Info()
IF @Cinfo = 0x55555
RETURN
PRINT 'Trigger Executed'
-- Actual code goes here
-- For simplicity, I did not include any code
GO
, Если Вы хотите препятствовать тому, чтобы триггер был выполнен, можно сделать следующее:
SET Context_Info 0x55555
INSERT dbo.Table1 VALUES(100)
ALTER TABLE tbl ОТКЛЮЧАЕТ ТРИГГЕРНЫЙ trg
http://doc.ddart.net/mssql/sql70/aa-az_5.htm
, я не понимаю значение Вашего 1-го абзаца хотя
Если Ваш триггер вызывает проблемы производительности в Вашем приложении, то лучший подход должен удалить все ручные обновления таблицы и потребовать, чтобы все обновления прошли вставить/обновить хранимые процедуры, которые содержат корректную логику обновления. Тогда можно удалить триггер полностью.
я предлагаю отклонить полномочия обновления таблицы, если ничто иное не работает.
Это также решает проблему дублирующего кода. Дублирование кода в SP обновления и в триггере является нарушением хороших принципов разработки программного обеспечения и будет проблемой обслуживания.
Так как Вы указываете, что триггер содержит логику для обработки всех обновлений, даже ручных обновлений, тогда это должно быть то, где логика находится. Пример, который Вы упоминаете, где хранимая процедура "будет заботиться об этой логике", подразумевает дублирующий код. Кроме того, если Вы хотите быть уверенными, что каждый оператор UPDATE имеет эту логику, примененную независимо от автора, тогда триггер является местом для него. Что происходит, когда кто-то создает процедуру, но забывает копировать логику все снова и снова? Что происходит, когда пора изменить логику?
Не отключайте триггер. Вы корректны, который отключит для любых параллельных транзакций.
, Почему Вы хотите отключить триггер? Что это делает? ПОЧЕМУ является триггер casuing проблемой? Это обычно - плохая идея отключить тигра с точки зрения целостности данных.
Я колебался немного на этом. С одной стороны, я - очень антитриггер главным образом, потому что это - еще одно место для меня для поиска кода, выполняющегося против моей таблицы, в дополнение к причинам, указанным в статье, связанной в сообщении вопроса.
, С другой стороны, если у Вас есть логика для осуществления стабильных и неизменных бизнес-правил или действий кросс-таблицы (как поддержание таблицы истории) тогда, было бы более безопасно получить это в триггер так авторы процедуры, и программисты не должны иметь дело с ним - это просто работает.
Так, моя рекомендация состоит в том, чтобы поместить необходимую логику в Ваш триггер, а не в этот proc, который, неизбежно вырастит к нескольким procs с тем же освобождением.
Полагайте, что перезапись триггера улучшает производительность, если производительность является проблемой.
Я соглашаюсь с некоторыми другими ответами. Не отключайте триггер.
Это - чистое мнение, но я избегаю триггеров как чумы. Я нашел очень немного случаев, где триггер использовался для осуществления правил базы данных. По моему опыту, существуют очевидные пограничные случаи, и у меня есть только свой опыт, на котором можно сделать этот оператор. Я обычно видел, что триггеры раньше вставляли некоторые реляционные данные (который должен быть сделан от бизнес-логики), для данных вставки в создание отчетов о таблице т.е. денормализовывание данных (который может быть сделан с процессом вне транзакции), или для преобразования данных в некотором роде.
существует законное использование для триггеров, но я думаю, что в повседневном программировании бизнеса они немногочисленны. Это не может помочь в Вашей текущей проблеме, но Вы могли бы рассмотреть удаление триггера в целом и выполнение работы, которую триггер делает некоторым другим способом.
Я просто столкнулся с той же проблемой и придумал следующее решение, которое мне подходит.
Создайте постоянную таблицу БД, которая содержит по одной записи для каждого триггера, который вы хотите отключить (например, refTriggerManager); каждая строка содержит имя триггера (например, strTriggerName = 'myTrigger') и битовый флаг (например, blnDisabled, по умолчанию 0).
В начале тела триггера посмотрите strTriggerName = 'myTrigger' в refTriggerManager. Если blnDisabled = 1, то возвращаемся без выполнения остального кода триггера, в противном случае продолжаем выполнение кода триггера.
В хранимой в памяти proc, в которой вы хотите отключить триггер, сделайте следующее:
BEGIN TRANSACTION
UPDATE refTriggerManager SET blnDisabled = 1 WHERE strTriggerName = 'myTrigger'
/* UPDATE таблица, которой принадлежит 'myTrigger', но которую вы хотите отключить. Поскольку refTriggerManager.blnDisabled = 1, 'myTrigger' возвращается без выполнения своего кода. */
UPDATE refTriggerManager SET blnDisabled= 0 WHERE triggerName = 'myTrigger'
/* Необязательный конечный код UPDATE, который запускает триггер. Поскольку refTriggerManager.blnDisabled = 0, 'myTrigger' выполняется полностью. */
COMMIT TRANSACTION
Все это происходит внутри транзакции, поэтому она изолирована от внешнего мира и не влияет на другие UPDATE в целевой таблице.
Кто-нибудь видит проблемы с этим подходом?
Билл