Saya memahami pertanyaan Anda sebagai 'ketika saya membuat perubahan skema, saya ingin memvalidasi semua prosedur yang masih dijalankan dengan benar dengan skema baru'. Yaitu. jika Anda menjatuhkan kolom yang direferensikan dalam SELECT dalam suatu prosedur, maka Anda ingin itu ditandai karena memerlukan perubahan. Jadi secara khusus saya tidak mengerti pertanyaan Anda sebagai 'Saya ingin prosedur untuk mengkompilasi ulang pada eksekusi berikutnya', karena pekerjaan itu diurus untuk Anda oleh mesin, yang akan mendeteksi perubahan versi metadata yang terkait dengan perubahan skema apa pun dan membuang yang ada rencana eksekusi yang di-cache.
Pengamatan pertama saya adalah bahwa apa yang Anda gambarkan dalam pertanyaan Anda biasanya merupakan pekerjaan UJI dan Anda harus memiliki langkah QA dalam proses penerapan Anda yang memvalidasi 'build' baru. Solusi terbaik yang dapat Anda miliki adalah dengan menerapkan serangkaian pengujian unit minimal yang, setidaknya, mengulangi semua prosedur tersimpan Anda dan memvalidasi eksekusi masing-masing untuk kebenaran, dalam penyebaran tes. Itu akan menghilangkan semua kejutan, setidaknya menghilangkannya di tempat yang menyakitkan (dalam produksi, atau di situs pelanggan).
Pilihan terbaik Anda berikutnya adalah mengandalkan alat pengembangan Anda untuk melacak dependensi ini. Visual Studio Database 2008 Database Edition menyediakan fungsionalitas seperti itu di luar kotak dan itu akan menangani validasi setiap perubahan yang Anda buat dalam skema.
Dan akhirnya opsi terakhir Anda adalah melakukan sesuatu yang mirip dengan apa yang disarankan KM:mengotomatiskan iterasi melalui semua prosedur Anda tergantung pada objek yang dimodifikasi (dan semua prosedur tergantung pada yang bergantung dan seterusnya dan seterusnya secara rekursif). Tidak akan cukup untuk menandai prosedur untuk kompilasi ulang, yang benar-benar Anda butuhkan adalah menjalankan ALTER PROCEDURE untuk memicu penguraian teksnya dan validasi skema (hal-hal sedikit berbeda dalam T-SQL vs. bahasa Anda yang biasa kompilasi/eksekusi siklus, 'kompilasi' itu sendiri hanya terjadi ketika prosedur benar-benar dijalankan). Anda dapat memulai dengan mengulangi melalui sys.sql_dependencies
untuk menemukan semua dependensi dari objek Anda yang diubah, dan juga menemukan 'definisi modul' dari dependensi dari sys.sql_modules
:
with cte_dep as (
select object_id
from sys.sql_dependencies
where referenced_major_id = object_id('<your altered object name>')
union all
select d.object_id
from sys.sql_dependencies d
join cte_dep r on d.referenced_major_id = r.object_id
)
, cte_distinct as (
select distinct object_id
from cte_dep)
select object_name(c.object_id)
, c.object_id
, m.definition
from cte_distinct c
join sys.sql_modules m on c.object_id = m.object_id
Anda kemudian dapat menjalankan 'modul' dependen dan membuatnya kembali (mis. lepaskan dan jalankan kode dalam 'definisi'). Perhatikan bahwa 'modul' lebih umum daripada prosedur tersimpan dan mencakup juga tampilan, pemicu, fungsi, aturan, default, dan filter replikasi. 'Modul' yang dienkripsi tidak akan memiliki definisi definisi yang tersedia dan agar benar-benar benar, Anda juga harus memperhitungkan berbagai pengaturan yang diambil dalam sys.sql_modules (ansi nulls, pengikatan skema, eksekusi sebagai klausa, dll.).
Jika Anda menggunakan SQL ynamic, itu tidak dapat diverifikasi. Itu tidak akan ditangkap oleh sys.sql_dependencies , juga tidak akan divalidasi dengan 'membuat ulang' modul.
Secara keseluruhan, menurut saya, opsi terbaik Anda, dengan selisih yang besar, adalah menerapkan validasi pengujian unit.
