SET statements for local variables are unreliable

[EnchoMishinevQC]

With the current design of the library, SET statements have a rather weird behavior. In short, before every top-level statement all local variables are redeclared with their initial value. This is a behavior hidden from the user and is potentially dangerous.

Examples

To illustrate the current behavior, here are some examples:

• Top-level SET

  DECLARE @A INT = 10
  SET @A = 5
  PRINT @A
  

  Will print 10. The SET is actually executed but has no effect since the variable is lost after batch execution and then redeclared with its initial value before the PRINT.

• SET in control flow

  DECLARE @A INT = 10
  IF 1 = 1
    BEGIN
      SET @A = 5
      PRINT @A
    END
  

  Will print 5 since the whole IF is executed as a single statement.

• And a mixed example that shows the inconsistent behavior

  DECLARE @A INT = 10
  IF 1 = 1
    BEGIN
      SET @A = 5
      PRINT @A
    END
  PRINT @A
  

  Will produce 5 followed by a 10, combining the behavior of the previous two examples.

Solution

It's unfortunately not easy to fix this in general, but it would be nice to at least add a warning log whenever SET statements are parsed in a script.

Note that simply banning SET statements at top level is not sufficient, because of cases like the third example - hence it is not trivial to statically determine which scripts would work as expected.