Home/ Questions/Q 1111183
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-17T02:30:30+00:00

I worked on a project that had the following requirement: TableA is the parent

  • 0

I worked on a project that had the following requirement:

TableA is the parent table. Whenever any children records of TableA are updated the ‘LastActivityDate’ field in TableA should be updated with the current UTC date.

Now, I know there are many ways of doing this. My post is NOT about the many different ways this could be accomplished.

I originally suggested using triggers for this requirement and our DBAs shot me down because they don’t want triggers in this DB (I don’t know why, and it isn’t important to my question). I ended up creating a stored proc that’s only purpose was to update TableA.LastActivityDate. I then coded the update/insert stored procedures of TableA’s children to call this stored proc. So, for example, a child’s update stored proc would look like this:

Create Procedure TableB_UPD
(
 @TableBId INT
 @TableBName VARCHAR(30)
)
AS
BEGIN
 UPDATE dbo.TableB
 SET TableBName = @TableBName
 WHERE
  (TableBId = @TableBId)

 DECLARE @TableAId INT
 SELECT
  @TableAId = TableAId
 FROM
  dbo.TableB
 WHERE
  (TableBId = @TableBId)

 EXEC dbo.TableA_LastActivityDate_UPD @TableAId
END

It’s pretty straight forward code, I call the dbo.TableA_LastActivityDate_UPD stored proc from within the TableB_UPD stored proc. When our DBAs saw this they refused to allow it in their DB. They told me that there is a huge performance hit from calling a stored procedure within a stored procedure. I have been unable to find any good online articles to support this statement (and the DBAs haven’t been able to give me any either).

I’ve seen this kind of code in lots of databases and never heard of any performance issues until now. My question is this: Can someone explain the performance issues around this type of code? I would greatly appreciate references to articles as well.

This is in SQL Server 2005.

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    When in doubt, look at execution plans and SQL Profiler to make sure your procedures perform optimally. They can tell you more about the situation than we ever could.

    The only issue I can think involving nested stored procedures that could even remotely be considered a problem would be error handling in nested stored procedures with transactions, but you don’t seem to have that going on here. And really, my example is more of a case of “Write your stored procedure properly.”

    As it stands though, nested stored procedures being a “huge performance hit” is news to me, and I sure can’t find anything supporting that statement either.

    • 0