Comments posted to this topic are about the item DDL Triggers Implementation
Hmm, sorry, but I disagree, I think this is pretty damn nasty.
A table for each type of object that is changed each having the same schema?
Columns defined for the tables but not actually used, instead the data is kept in the XML column and the view extracts from it, surly with performance implications.
I use this scripts to create in someone database,then I create the new procedure,
report error following:
Invalid object name 'Sch_AuditDdl.t_procedure'.?
how to resolve it ?
How the data will be store, used and extract that depends on your application, the word nasty is not the word I will used when I don't understand or disagree with something. This implementation is only a guide line that someone agree or disagree is understandable as long as a proper alternative is provided. Here is the scenario:
On a developers shop where source control hasn't been fully implemented at the database level, ddl triggers is a good way to store a historical record of most objects changes.
If most objects normally never change then please explain how that can cause performance issues. ( This implementation shouldn't be in a production environment)
Please ensure than when create object didn't create a separate schema using the user login. The error means or the object doesn't exist or there is a mismatch on the object name. Please provide more information about the error.
Change [Sch_AuditDdl] to proper schema most of the time (dbo).
or create a new schema with name [Sch_AuditDdl]
Look here for a full solution: http://www.sqlservercentral.com/Forums/Topic948331-149-1.aspx
Viewing 8 posts - 1 through 7 (of 7 total)