• David McKinney (1/2/2009)

    ANY SOLUTION based on sysdepends isn't going to work.

    The obvious solution based on sysdepends - running alterproc for the SP with no changes before using sysdepends - works better than your proposed solution: it avoids listing tables that are mentioned only in comments.

    Your solution suffers from a rather obvious defect: it doesn't handle views; that can be fixed rather trivially; avoiding comments is rather harder; handling dependencies arising from access to other databases or by the many indirect access mechanisms is quite hard too

    If one really wants to understand dependencies between SPs and tables, one has to consider (i) tables in the current database accessed by the SP; (ii) tables in other databases accessed by the SP; (iii) tables (in this or other databases) involved in views accessed by this SP; (iv) tables (in this or other databases) used by SPs, or UDFs called by the SP; and (v) tables accessed (including indirect access through views or further triggers of SP or Function calls) by triggers fired by actions of this SP. Your current script is useful in a single database world with no triggers, views or functions and where no SP calls any other SPs, but not much use elsewhere.

    It's quite (but not very) hard to write something that does the job properly in SQLS 2000; it's a bit easier in SQLS 2005 (recursive queries help).

    Tom