I was in the same boat about 10 years ago. I wasted time confirming that sql scripts were deployed to different production databases. I needed to chase down logs and contact dba's through email, etc... It was a big time-waster.
My team created a standard adhoc script template to help with this. The goal of the template was:
1) confirm script is deployed to the correct database
2) inserts record into log table (start date, end date, description, etc...)
3) updates log table when script completes / fails
We asked the script runners / dba's to reject any script that doesn't use the standard template. They reviewed and contributed to the template and were totally onboard.
The majority of our script writers use sql prompt, which allows for sql snippets - so everyone is used to starting out with this standard template as they write these scripts.
No issues since we implemented this. And I can confirm when and where scripts ran quickly.
My team created a standard adhoc script template to help with this. The goal of the template was:
1) confirm script is deployed to the correct database 2) inserts record into log table (start date, end date, description, etc...) 3) updates log table when script completes / fails
We asked the script runners / dba's to reject any script that doesn't use the standard template. They reviewed and contributed to the template and were totally onboard.
The majority of our script writers use sql prompt, which allows for sql snippets - so everyone is used to starting out with this standard template as they write these scripts.
No issues since we implemented this. And I can confirm when and where scripts ran quickly.