when running stored procedure, which records got added, updated & deleted

  • When Running a stored procedure how i can track which records got created, updated and deleted as a result of execution of Stored Procedure.

    Is this Possible? I want to know the DML's.

  • The stored procedure is the DML.

    If you want to know which rows are updated, and the stored procedure isn't updating specified rows (e.g., ID parameter),  then you'll probably need trigger(s) to store that info into a tracking table.

  • You can also use the OUTPUT clause to return this information. If you want to know later, you have to store this information somewhere. This isn't tracked by SQL SErver by default

    OUTPUT - https://learn.microsoft.com/en-us/sql/t-sql/queries/output-clause-transact-sql?view=sql-server-ver16

  • The best way to track this information is have it be part of the Stored Procedure you are running and have a table that houses this information in a logical manner.

    Yes, in some situations this information can be critical, as we track this information for some of the stored procedures we run but, as stated, we built this feature into the stored procedure since that is the most efficient place to have it exists.

  • You could look to Change Data Capture as a way to see all the data manipulation on the system. It does require quite a bit of setup & maintenance though, so read through the docs carefully.

    "The credit belongs to the man who is actually in the arena, whose face is marred by dust and sweat and blood"
    - Theodore Roosevelt

    Author of:
    SQL Server Execution Plans
    SQL Server Query Performance Tuning

  • To track changes from a stored procedure:

    • Output Parameters: Use output parameters to capture the number of affected rows for inserts, updates, and deletes.
    • Audit Tables: Store changes in separate audit tables within the procedure.
    • Change Data Capture (CDC): If supported, use CDC to automatically track changes.
    • Triggers: Implement triggers to log changes to a separate table.
    • Transaction Logs: Query transaction logs for detailed change info.
    • Versioning/Timestamp Columns: Check versioning/timestamp columns after the procedure runs.Choose the method that suits your needs and database capabilities. Consider performance implications.
  • I would have a log table to keep track of the updates, etc, and maintain this table regularly.  It is quite simple.

     

    DBASupport

Viewing 7 posts - 1 through 6 (of 6 total)

You must be logged in to reply to this topic. Login to reply