SqlContext

SqlContext exposes the objects used to resolve SQL bind and into expressions. It does not turn C# method-local variables into reflectable members. Ice Porter first places the relevant generated variables in a locals object, then establishes a context for that object and the owning instance.

Constructor Arguments

In the reviewed desktop/web PPJ 5.0 implementation, the two-argument constructor is SqlContext(object locals, object container):

using (new SqlContext(locals, this))
{
    // Prepare, execute, and fetch while the required context is active.
}

The locals object comes first; the owner comes second. Both parameters are typed as object, so reversing them can compile without a warning. It changes which object is exposed as Locals and which as Container, and can change resolution when names overlap or a lookup depends on its scope.

The single-argument constructor establishes a locals object without a container. It should not be interpreted as a universally equivalent replacement for the two-argument form.

What the Scope Contains

SqlContext.Current
    ├─ Locals    → generated locals/parameters object
    └─ Container → owning application object

SAL visual context → current form/item context where needed
Global context     → registered application globals where applicable

The resolver uses the available contexts to find symbols in bind expressions and destinations for into values. Keep the generated scope structure when extracting helper methods; moving the same SQL text into another context can change what an unqualified name means. See Bind and Into Variables and SalCompileAndEvaluate.

Scope Lifetime

Nested scopes restore the preceding context when disposed. C# using performs that disposal on normal return and when an exception leaves the block. The context walkthrough shows the sequence alongside SalContext.

Context disposal is not a database operation: it does not commit or roll back a transaction, close a reader, or disconnect a SQL handle. Those resources have their own owners and lifetimes. Keep the context active during every operation that still needs to resolve a bind or into expression, including fetching where applicable.

Do not share a context object across threads or assume the current stack follows an asynchronous continuation or a different web session. Establish the target's supported context where the work executes. When troubleshooting, inspect both SqlContext.Current.Locals and .Container; a successful cast or compilation does not prove the intended instances were supplied.