Under the covers, every EQQ query is executed via a parameterized command with typed bindings. No string concatenation, no format-string templating, no runtime SQL assembly from user input. This post walks through what actually happens when an end user clicks Run.
Phase 1 - resolve the query

EQQ reads the query definition from its metadata tables (not from cached SQL strings). The definition holds the parameter declarations, the generated SQL body, the target database connection, and the role-based predicate set.
Phase 2 - bind parameters
End-user inputs are coerced to their declared types. A date parameter arrives as a DateTime, not a string. An integer arrives as int. Any coercion failure is caught before a single byte of SQL reaches the database.
Phase 3 - merge role-based predicates
If the query has a role-scoped predicate (e.g. Region = @UserRegion), the predicate is injected as a typed parameter, not a string substitution. Users cannot escape their scope by typing clever inputs.
Phase 4 - execute
The statement is sent as a parameterized command. SQL Server (or MySQL / PostgreSQL) plan-caches it, so the same query with different parameters reuses the same execution plan. Fast and predictable.
Phase 5 - audit and return
Before the grid renders, EQQ writes an audit record: user, query, parameters (with sensitive values masked), rows returned, elapsed time, errors. Then the rows stream back to the browser.
-- Conceptually, every run is equivalent to:
EXEC sp_executesql
N'SELECT ... FROM dbo.vOrders WHERE OrderDate BETWEEN @p0 AND @p1',
N'@p0 datetime, @p1 datetime',
@p0 = '2026-01-01', @p1 = '2026-03-31';
This is the same pattern a well-written .NET or JDBC app would use. EQQ just gives you this rigor for free, no matter who writes the query.
Try EQQ free. Spin up a free trial and run your first governed query today. Start Free Trial →
Key Terms
- JDBC - Java Database Connectivity - the standard Java API for connecting to and querying relational databases.