Bind and Into Variables

The PPJ Framework fully supports all kinds of bind and into variables and expressions. We use a very fast technique that generates and caches IL code on the fly when accessing class members at runtime. There is a special script execution engine built in the PPJ Framework that is used anytime there is the need for runtime interpretation. The scripting engine is used for: evaluating bind expressions, updating into variables, feeding reports' input items, execute SalCompileAndEvaluate expressions, and also for the implementation of XSalScript.3

See the Scope Resolution section in SalCompileAndEvaluate for a description of how the PPJ Framework resolves the scope at runtime.

Support for bind variables is one of the most important features of the PPJ Framework because embedded SQL is very widespread in all SAL applications and removing it is equivalent to re-engineering the entire application.

We also support local bind variables by extracting all the locals into a special inner class named SqlLocals and replacing all the references to local and parameter variables (also called automatic variables) with the corresponding member of the locals instance. Since it is impossible to safely determine which local variables are used as bind variables, Ice Porter extracts all locals. If the application doesn't use local variables as bind variables, the locals extraction is not necessary and can be turned off.

For example:

Function: Test
 Local Variables
         String: sName
 Actions
         Call SqlPrepareAndExecute(hSql, "select name from companies into :sName")
         Call SqlFetchNext(hSql, nRet)
         Call SalMessageBox(sName, "", 0)

Is translated to:

public SalNumber Test()
{
 SqlLocals.Test locals = new SqlLocals.Test();
 using (new SqlContext(this, locals))
 {
         hSql.PrepareAndExecute("select name from companies into :sName");
         hSql.FetchNext(ref nRet);
         Sal.MessageBox(locals.sName, "", 0);
 }
}

The SqlLocals.Test class contains the declaration of the local variables from the Test function. This technique allows us to access the locals at runtime, which would otherwise be impossible since automatic variables live on the stack and cannot be inspected using reflection.

The entire function body is enclosed in the SqlContext block (with the using/dispose technique) in order to save the current context and allow the Sql implementation in the PPJ Framework to access the right instances.