# 8.3 Transformation performance in Vision client **URL:** \ **Category:** Ignition\ **Tags:** vision, ignition83\ **Created:** [September 25, 2025, 3:02pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975 "2025-09-25T15:02:28Z")\ **Posts on this page:** 1\ **Showing post:** 3
**Author:** ![paul-griffith](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/paul-griffith/32/37249_2.png) [@paul-griffith](https://forum.inductiveautomation.com/u/paul-griffith)\ **Post date:** [September 25, 2025, 4:35pm UTC](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975/3 "2025-09-25T16:35:17Z")
In 8.3: - The non-"prep" variants of direct SQL query functions (`runQuery`, `runScalarQuery`, `runUpdateQuery`) are deprecated in all scopes, because they're strictly worse than the `prep` variants - there's literally no reason to use them. - The `runNamedQuery` and `runSFNamedQuery` functions are deprecated in all scopes because: 1. It had a fundamental signature incompatibility between client and gateway scope with the `project` parameter 2. The idea of a single named query function issuing any kind of query (query, scalar, or update) was misleading at best. The recommended replacements are `system.db.execQuery`, `execUpdate`, `execScalar`, and `execUpdateAsync`. > [@fema](#): > > system.db.runPrepQuery is deprecated in Vision with no replacement listed (what should I use now?) You should use named queries, _or_ if you need more dynamic SQL, you should send a message using `system.util.sendMessage` and invoke a message handler on the gateway that runs `system.db.runPrepQuery`. There's a fundamental security issue with running 'raw' DB queries from Vision, hence why it's been gated behind the 'Legacy Database Access' permission in your project properties since Ignition 7.9.4. > [@fema](#): > > system.db.execSProcCall is replaced by system.db.storedProcedure. This part of the 8.1 to 8.3 upgrade guide, which I'm assuming is where you're seeing that: | System Function | Deprecated | Replacement System Function | | --- | --- | --- | | `system.db.beginTransaction` | No | `system.db.transaction` | | `system.db.beginNamedQueryTransaction` | No | `system.db.transaction` | | `system.db.closeTransaction` | No | `system.db.transaction` | | `system.db.commitTransaction` | No | `system.db.transaction` | | `system.db.rollbackTransaction` | No | `system.db.transaction` | | `system.db.createSProcCall` | No | `system.db.storedProcedure` | | `system.db.execSProcCall` | No | `system.db.storedProcedure` | Is just wrong - we haven't yet introduced these new functions, so they shouldn't be in the migration guide. No matter when they are, since 8.3.0 is already out the existing functions to manage transactions/stored procedures will not be deprecated until our next major release. * * * All that said - as ever, just because a function is deprecated does not mean it is going to **break** , now or in the immediate future. With **literally one exception** in the last decade, we do not remove scripting functions after they've been added. Eventually they **may** functionally stop doing anything (e.g. the `system.alert` functions, originally deprecated in 7.6 / **2013** , stopped doing anything in 8.3), but they will not be removed, and in the unlikely event we can't provide equivalent functionality automatically, it will be clearly marked in the upgrade guide. With 8.3, this situation actually got _more_ clear for you as an end user - previously, we could only show or hide functions entirely, with no ability to "soft" deprecate them. The plan is to use this new capability to stage deprecations for the duration of an entire major release, and only hide them in the next major release. 8.3 also has a larger than usual swathe of deprecations because of this new capability and this new guarantee - so we packed a lot of long-due reorganization in. In the long run, this makes things more clear for new users. * * * All **that** said, > [@fema](#): > > system.vision.transform This function is **literally** identical to the 8.1 version. `system.vision.transform` simply calls `system.gui.transform` for you. Any difference in behavior there is either environmental, or due to some other factor in the 8.3 upgrade, but I can't really think of what it would be. But: > [@fema](#): > > `system.util.invokeAsynchronous(action)` This is **not safe**. Any interaction with Vision components, even indirectly via `system.gui.transform`, must take place on the EDT. `system.gui.transform` is non-blocking by nature - that's why it accepts a callback argument. --- _[View the full topic](https://forum.inductiveautomation.com/t/8-3-transformation-performance-in-vision-client/110975)._