Asked a while back - think I'll try again!

Collapse
This topic is closed.
X
X
 
  • Time
  • Show
Clear All
new posts
  • Gary DeRousse

    Asked a while back - think I'll try again!

    This pertains to SQL Server 2000

    Do others have the problems that we have in our company, where we have
    a field from a table, and need to know all the SQL Server processes
    that may change that value? I'm still hoping somebody can tell me of a
    tool, or set of queries or something that will document the fields in
    the tables and the processes that affect them, along with the values
    that it sets. For example:

    TableA.FieldA:
    sp_InsertNewRec : sets field to Null when new record created
    sp_ChangeStatus : sets field to the value of the parameter passed in
    tr_LogChanges: sets field to be the current datetime

    Maybe we're just too sloppy at my company, but it seems to be fairly
    obvious need to have some sort of automated process that can provide
    that documentation. With thousands of fields, hundreds of stored
    procedures, triggers, DTS's etc..., documenting this information is a
    VERY daunting task. Any help at all would be appreciated.

    Gary
  • Chad Gould

    #2
    Re: Asked a while back - think I'll try again!

    On 6 Nov 2003 15:19:44 -0800, garyderousse@ya hoo.com (Gary DeRousse)
    wrote:[color=blue]
    >Do others have the problems that we have in our company, where we have
    >a field from a table, and need to know all the SQL Server processes
    >that may change that value? I'm still hoping somebody can tell me of a
    >tool, or set of queries or something that will document the fields in
    >the tables and the processes that affect them, along with the values
    >that it sets. For example:[/color]

    It would perhaps be possible, though not trivial, to construct a
    report that extracts what fields and what tables are affected by
    procs, triggers, functions, etc. by parsing the entire database's SQL
    (which you can create in Enterprise Manager).

    It would be very difficult to describe the functionality that said
    proc does on said table, since the SQL language is so dynamic. Such
    basic technical documentation should have been done by the coder when
    the procedure was created, if this level of thoroughness was desired.
    You'll find out that reverse engineering a SQL server application is
    fairly time consuming. :)
    ___________
    To replay by email, chop off the head!

    Comment

    Working...