This content has been marked as final. Show 4 replies
I'm not sure that I see what relationship this has to making code changes. Code changes are DDL not DML.
You would call this procedure from whatever procedure you are using to do DML
or you could call the procedure from a trigger on whatever table you wanted.
BEGIN secure_dml; <<do some DML>> END;
Of course, I'm not sure why you would want to restrict people from making DML changes outside of business hours. It seems reasonable to suspect that people will occasionally want to start working before 8am or stay after 6pm or work on a weekend (particularly if you ever envision supporting users in multiple time zones). Explaining to the business that allowing them to finish the changes they are working on will require a code change because they couldn't get them done by 6pm seems like a poor career move.
If you wanted to apply this to DDL (despite the name of the procedure), you could potentially invoke it from a DDL trigger. But, again, that doesn't seem like the greatest idea. A developer's ability to make code changes in production should be nonexistant. Changes should be made by a DBA based on scripts stored in source control. Code changes are almost always made before or after normal business hours-- the business is rarely willing to let the system be unavailable during normal hours just for the convenience of the DBAs so that they don't have to apply changes after hours.
KinsaKaUy? wrote:Looking at the example posted, there's not much to learn.
I am browsing lots of procedures in our database, so I could learn different technics from them.
Programming standards and naming conventions? Missing!
Changing a date into a string to perform date logic/conditional branching? Wrong!
Hard coding system calls (like <i>raise_application_error</i>) and not wrapping these into custom wrapper procedures or functions? Highly questionable!