Comments
Sort by recent activity
OK... let's try a workaround. For each table, X, that may be referenced by dynamic SQL, I include something like this in the body of the proc:
declare @testfail int
set @testfail = 0
if @testfail = 1 select top 1 * from X where 0 = 1
It seems to provide the dependency tracking information I need but it won't ever return anything and doesn't seem to change the way the proc runs.
Does anyone think there is a disadvantage to this that I've overlooked? There's probably a performance hit but when compared to the performance of assembling and executing a string, I doubt that it's a big deal. / comments
OK... let's try a workaround. For each table, X, that may be referenced by dynamic SQL, I include something like this in the body of the proc:
declare @testfail int
set @testfail = 0
if @testfail ...
I'm unfamiliar with SQL Search but searching and writing down dependencies... well, I could do almost that well with a couple of queries against sysdepends and a spreadsheet and then searching and dressing my spreadsheet up with manually added entries, no?
Or I could just do the basic dependencies into a spreadsheet, search for EXECs and send that list of stored procs offshore to get a list of further dependencies at $15/hour.
OK... I get that there's no feature in the product to do this, which is a huge disappointment, but there are certainly other dbas out there that have dynamic SQL. "Have you considered using SQL Search?" is a disappointing answer. / comments
I'm unfamiliar with SQL Search but searching and writing down dependencies... well, I could do almost that well with a couple of queries against sysdepends and a spreadsheet and then searching and ...