Write protect some rows in a table - sql-server

Question

I have a situation where I need to write protect certain rows of a table based on some condition (actually a flag in a foreign table). Consider this schema:
CREATE TABLE Batch (
Id INT NOT NULL PRIMARY KEY,
DateCreated DATETIME NOT NULL,
Locked BIT NOT NULL
)
CREATE UNIQUE INDEX U_Batch_Locked ON Batch (Locked) WHERE Locked=0
CREATE TABLE ProtectedTable (
Id INT NOT NULL IDENTITY PRIMARY KEY,
Quantity DECIMAL(10,3) NOT NULL,
Price Money NOT NULL,
BatchId INT NULL)
ALTER TABLE ProtectedTable ADD CONSTRAINT FK_ProtectedTable_Batch FOREIGN KEY (BatchId) REFERENCES Batch(id)
I want to prevent changes to Quantity and Price if the row is linked to a Batch that has Locked=1. I also need to prevent the row from being deleted.
Note: U_Batch_Locked ensures that at most one batch can be unlocked at any time.
I have tried using triggers (yikes) but that caused more issues because the trigger rolls back the transaction. The update typically happens in a C# client that performs multiple updates (on multiple tables) in a single transaction. The client continues with the updates regardless of errors and at the end of the transaction rolls it back if any errors occurred. This way it can collect all/most of the constraint violations and let the user fix them before trying to save the changes again. However, since the trigger rolls back the transaction when the constraint is not satisfied, subsequent updates start their own auto transactions and are in fact committed. The final rollback issued by the client at the end of the batch simply fails.
I have also found this blog post: Using ROWVERSION to enforce business rules, which although seems to be what I need it requires the foreign key to have the opposite direction (i.e the protected table is the parent in the parent-child relationship while in my case the protected table is the child)
Has anyone done something like this before? It seems like a not so uncommon business requirement, yet I have not seen proper solution yet. I know I can implement this on the client side, but that leaves room for error: what if someone changes these using direct SQL (by mistake), what if an upgrade/migration script or the client itself has a bug and fails to enforce the constaint?

Answer 1

After lots of searching and trial and error, I ended up using INSTEAD OF triggers to check for the constraint and if necessary raise the error and skip the operation. Referring to the schema in the original question, here are the required triggers:
Update trigger:
CREATE TRIGGER ProtectedTable_LockU ON ProtectedTable
INSTEAD OF UPDATE
AS
SET NOCOUNT ON;
IF UPDATE(Quantity) OR UPDATE(Price)
AND EXISTS(
SELECT *
FROM inserted i INNER JOIN deleted d ON d.Id = i.Id
LEFT JOIN Batch b ON b.Id = d.BatchId
WHERE b.Locked <> 0 AND
(i.Quantity <> d. Quantity OR i.Price <> d.Price))
BEGIN
RAISERRROR('[CK_ProtectedTable_DataLocked]: Attempted to update locked data', 16, 1)
RETURN
END
UPDATE pt
SET Quantity = i.Quantity,
Price = i.Price,
BatchId = i.BatchId
FROM ProtectedTable pt
INNER JOIN deleted d ON d.Id = pt.ID
INNER JOIN inserted i ON i.Id = d.Id
Delete trigger:
CREATE TRIGGER ProtectedTable_LockD ON ProtectedTable
INSTEAD OF DELETE
AS
SET NOCOUNT ON;
IF EXISTS(
SELECT *
FROM deleted d
LEFT JOIN Batch b ON b.Id = d.BatchId
WHERE b.Locked <> 0)
BEGIN
RAISERRROR('[CK_ProtectedTable_DataLocked]: Attempted to delete locked data', 16, 1)
RETURN
END
DELETE pt
FROM ProtectedTable pt
INNER JOIN deleted d ON d.Id = pt.ID
Of course one could create a view and put the triggers on the view. That way you could also avoid the conflict between INSTEAD OF triggers and FOREIGN KEY ON DELETE/ON UPDATE rules.
It's ugly, I don't like it at all, but it's the only solution that actually works and behaves more or less like a regular database constraint (database constraints are checked before modifying the data). I have not yet tested this extensively and I am not sure there are no issues with it. I am also worried about race conditions (e.g. what if Batch is modified during the execution of the trigger? should I / can I include lock hints to ensure integrity?)
PS: Regardless of the bad application design, this is still a reasonable requirement. In certain cases it is also a legal one (you have to prove there is no way certain records can be altered after some conditions are met). That is why the question pops up now and then in SO, and there is no definite solution. I find this solution better than using AFTER triggers as this behaves more like a normal database constraint.
Hopefully this may help others in similar situations.

Answer 2

Rather than granting users access to the table directly, create a simple VIEW using the CHECK OPTION option and only grant users permissions to apply modifications via that view. Something like:
CREATE VIEW BatchData
WITH SCHEMABINDING
WITH CHECK OPTION
AS
SELECT pt.Id, pt.Quantity, pt.Price, pt.BatchId
FROM
dbo.ProtectedTable pt
INNER JOIN
dbo.Batch b
ON
pt.BatchId = b.Id
WHERE
b.Locked = 0
So long as all inserts, updates and deleted are channelled through this view (which as I say above, you constrain via permissions) then they can only be applied to the open batch