My application involves using submitting data (the “request”) from a form into an SQL Server 2005 database, for later review and approval by a supervisor. Users should have permission to insert a new request, but not be able to modify the ones they have already submitted.
With a single table, this is straightforward: grant them the INSERT privilege only without the UPDATE privilege. But the request actually spans two tables, with a one-to-many relationship. I need to prevent the user from inserting additional child rows for an existing request. Ideally, this should be enforced at the database level: allow a parent row and one or more child rows to be inserted in the same transaction, but once that transaction is committed prevent new child rows from being inserted with that foreign key.
What’s the best way to achieve this? Are there any ways to enforce this special flavour of “referential integrity” without triggers? And if triggers are they only way, then how can I test that the parent row has been inserted within the current transaction?
Stored procedure or trigger
If you grant rights on the child table, then they’ll be able to write.
A trigger will disallow the write and a stored procedure allows you to prevent the write in the first place because only the stored proc writes to the tables.
There is no “native” referential integrity that can capture your business logic because it’s custom to your situation.