Louis' organization has some pretty standard coding policies. Two key policies are that database access is allowed only via stored procedures and that all code must be reviewed before being deployed to the testing environment. There's no exception to this, meaning that everyone's code, even the highly-paid consultants' code, must go through review. One of the senior consultants on the team recently submitted this code for review ... 

CREATE PROCEDURE [DynamicTPSBuilder]
(
  @SQL VARCHAR(8000) 
) AS 
BEGIN

  SET NOCOUNT ON
  SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

  EXEC (@SQL)

  RETURN(-1)

END

The reviewers rejected it saying that, in addition to completely defeating the purpose of using stored procedures, the code allowed for a massive SQL Injection attack. Their message really didn't seem to get across, so they spent quite a bit of time explaining exactly how a SQL Injection Attack would work.

After having one of those "oh, duh!" moments, the consultant agreed to go back and fix it. A few days later, he brought this to the code review ... 

CREATE PROCEDURE [SADynamicTPSBuilder]
(
  @SELECTS VARCHAR(8000),
  @JOINS VARCHAR(8000)
) AS
BEGIN

  SET NOCOUNT ON
  SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED

  EXEC (@SELECTS + @JOINS)
  
  RETURN(-1)

END
[Advertisement] BuildMaster allows you to create a self-service release management platform that allows different teams to manage their applications. Explore how!