SSIS For Loop resetting the variable value - visual-studio-2010

Question

In SSIS (MS Visual Studio 2010) I have created a SQL Task with Single Row output (int32) that is passed to User::Variable. Then I have a "For Loop" that I want to run as many times as the integer from the SQL Task query equals to. I have setup the For Loop with the following:
InitExpression: #Start = 1
EvalExpression: #Variable >= #Start
AssignExpression: #Start = #Start+1
In my test example, the #Variable is set to 4 by SQL Task query, and the loop runs fine for the first loop, but then immediately finishes reporting package successfully executed (after just 1 loop when it should have looped 4 times).
It is like the #Variable resets to default value (0) after the first loop is done instead of keeping the original value (4).
How can I fix this?

Answer 1

What's more likely: using the name Variable, which SSIS defaults to for a new variable, is incompatible with anything in an SSIS package or that you've done something that you haven't shown?
I have created a package with two Variables, Variable and Start. I have populated Variable from a SQL Query with the value of 4 and then used a For Loop as described and I did not experience early termination.
My package, variables with design time values set to zero.
My For Loop Container
Last iteration of the loop
Reproducible results
Biml, the Business Intelligence Markup Language, describes the platform for business intelligence. Here, we're going to use it to describe the ETL. BIDS Helper, is a free add on for Visual Studio/BIDS/SSDT that addresses a host of shortcomings with it.
You will need to edit line 3 to be a valid OLE DB Connection Manager for your machine (point to a SQL Server installation and possibly update the Provider)
<Biml xmlns="http://schemas.varigence.com/biml.xsd">
<Connections>
<OleDbConnection Name="CM_OLE" ConnectionString="Data Source=localhost\dev2012;Initial Catalog=tempdb;Provider=SQLNCLI11;Integrated Security=SSPI;" />
</Connections>
<Packages>
<Package Name="so_25878932" ConstraintMode="Linear">
<Variables>
<Variable Name="Variable" DataType="Int32">0</Variable>
<Variable Name="Start" DataType="Int32">0</Variable>
</Variables>
<Tasks>
<ExecuteSQL ConnectionName="CM_OLE" Name="SQL Variable" ResultSet="SingleRow">
<DirectInput>SELECT 4 AS Variable;</DirectInput>
<Results>
<Result Name="0" VariableName="User.Variable"/>
</Results>
</ExecuteSQL>
<ForLoop ConstraintMode="Linear" Name="FLC Go">
<InitializerExpression>#Start = 1</InitializerExpression>
<LoopTestExpression>#Variable >= #Start</LoopTestExpression>
<CountingExpression>#Start = #Start + 1</CountingExpression>
<Tasks>
<!--
Pilfered from http://bimlscript.com/Snippet/Details/74
-->
<Script
ProjectCoreName="ST_232fecafb70a4e8a904cc21f8870eed0"
Name="SCR Emit Variable and Start">
<ReadOnlyVariables>
<ReadOnlyVariable VariableName="User.Variable" />
<ReadOnlyVariable VariableName="User.Start" />
</ReadOnlyVariables>
<ScriptTaskProject>
<ScriptTaskProject ProjectCoreName="ST_c41ad4bf47544c49ad46f4440163feae" Name="TaskScriptProject1">
<AssemblyReferences>
<AssemblyReference AssemblyPath="Microsoft.SqlServer.ManagedDTS.dll" />
<AssemblyReference AssemblyPath="Microsoft.SqlServer.ScriptTask.dll" />
<AssemblyReference AssemblyPath="System.dll" />
<AssemblyReference AssemblyPath="System.AddIn.dll" />
<AssemblyReference AssemblyPath="System.Data.dll" />
<AssemblyReference AssemblyPath="System.Windows.Forms.dll" />
<AssemblyReference AssemblyPath="System.Xml.dll" />
</AssemblyReferences>
<Files>
<File Path="AssemblyInfo.cs">
using System.Reflection;
using System.Runtime.CompilerServices;
//
// General Information about an assembly is controlled through the following
// set of attributes. Change these attribute values to modify the information
// associated with an assembly.
//
[assembly: AssemblyTitle("ST_c41ad4bf47544c49ad46f4440163feae.csproj")]
[assembly: AssemblyDescription("")]
[assembly: AssemblyConfiguration("")]
[assembly: AssemblyCompany("Varigence")]
[assembly: AssemblyProduct("ST_c41ad4bf47544c49ad46f4440163feae.csproj")]
[assembly: AssemblyCopyright("Copyright # Varigence 2013")]
[assembly: AssemblyTrademark("")]
[assembly: AssemblyCulture("")]
[assembly: AssemblyVersion("1.0.*")]
</File>
<File Path="ScriptMain.cs">
using System;
using System.Data;
using Microsoft.SqlServer.Dts.Runtime;
using System.Windows.Forms;
// if SSIS2012, use the following line:
[Microsoft.SqlServer.Dts.Tasks.ScriptTask.SSISScriptTaskEntryPointAttribute]
// if earlier version, use the next line instead of the above line:
// [System.AddIn.AddIn("ScriptMain", Version = "1.0", Publisher = "", Description = "")]
public partial class ScriptMain : Microsoft.SqlServer.Dts.Tasks.ScriptTask.VSTARTScriptObjectModelBase
{
enum ScriptResults
{
Success = Microsoft.SqlServer.Dts.Runtime.DTSExecResult.Success,
Failure = Microsoft.SqlServer.Dts.Runtime.DTSExecResult.Failure
};
public void Main()
{
int i = 0;
MessageBox.Show(string.Format("{0}:{1}", Dts.Variables[i].Name, Dts.Variables[i].Value));
i++;
MessageBox.Show(string.Format("{0}:{1}", Dts.Variables[i].Name, Dts.Variables[i].Value));
Dts.TaskResult = (int)ScriptResults.Success;
}
}
</File>
</Files>
</ScriptTaskProject>
</ScriptTaskProject>
</Script>
<ExecuteProcess Executable="cmd.exe" Name="EP Do nothing" Arguments="/C">
</ExecuteProcess>
</Tasks>
</ForLoop>
</Tasks>
</Package>
</Packages>
</Biml>
Root cause guess
Variables can be created at different scopes within a package. I would presume that since a variable is created with the default name of Variable two, or more, such variables exist with the same name but at different application scopes. Thus, if I had defined a second SSIS variable named Variable on my ForLoop Container, it would start with a value of 0, unless defined otherwise. My package execution would begin, assign the value of 4 to my package level Variable. Control switches to my ForLoop Container. The Variable defined there wins from a scoping perspective so my value there is 0, not 4 because nothing has initialized it. In that case, the ForLoop would never fire as the terminal condition has already been met. For your case, I further presume that someone initialized that variable to 1.
Notice the Scope here, this is what I believe to be your root cause.

Answer 2

Solution:
DO NOT name SSIS variables #Variable. Doing so will unintentionally cause the variable value to pick up exit codes of other processes in the package as they run.
In my case the #Variable value would automatically change to 0 after a successfully run Execute Process Task with exit code 0; or change to -1073741510 when that process run failed.