# SQL UPDATE statements silently fail in script console **URL:** \ **Category:** Ignition\ **Tags:** scripting, perspective\ **Created:** [July 19, 2026, 6:17pm UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457 "2026-07-19T18:17:58Z")\ **Posts on this page:** 6\ **Page:** 1
**Author:** ![TT-ignit](https://avatars.discourse-cdn.com/v4/letter/t/439d5e/32.png) [@TT-ignit](https://forum.inductiveautomation.com/u/TT-ignit)\ **Post date:** [July 19, 2026, 6:17pm UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457/1 "2026-07-19T18:17:59Z")
Hello all I'm here to get help eliminating possible issues on my end before claiming there's a bug with Ignition. I'm writing some library functions that generically handle reporting requests. While doing so I'm breaking things apart as much as possible so that someone wanting to inspect the pipeline can call individual pieces of it from the script console. In doing so I noticed that I was unable to update my database from the console context, even with the correct read/write comm mode enabled. I boiled it down to as simple of a query as I could. This query: `UPDATE READS_ReportRequests SET [Status] = 'Processing'` Runs perfectly fine in any DBM I've tried it with. I then reset the value of the `Status` column for the singular row in the table to something else. Recontextualizing it for use in Ignition script console: ```python query = "UPDATE READS_ReportRequests SET [Status] = 'Processing'" rows = system.db.runPrepUpdate(query, []) print rows ``` Displays `0` and, checking the table, has not done anything. Adding things like targetting the specific PK of that singular row doesn't change anything. Running a similar script as an `onActionPerformed` for a button in a Perspective view: ```python def runAction(self, event): query = "UPDATE READS_ReportRequests SET [Status] = 'Processing'" rows = system.db.runPrepUpdate(query, []) system.perspective.print(rows) ``` Prints `1` and the update is reflected in the table. This _feels_ like a bug, but am I missing some context for why this shouldn't work? I'm using SQL Server, with an admittedly outdated JDBC I've been trying to get updated. But the ability to get this working on a Perspective view/gateway context suggets to me that isn't the issue. ---
**Author:** ![TT-ignit](https://avatars.discourse-cdn.com/v4/letter/t/439d5e/32.png) [@TT-ignit](https://forum.inductiveautomation.com/u/TT-ignit)\ **Post date:** [July 19, 2026, 6:26pm UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457/2 "2026-07-19T18:26:37Z")
Doing something like: ```python query = """ UPDATE READS_ReportRequests SET [Status] = 'Processing'; SELECT @@ROWCOUNT AS RC; """ rc = system.db.runScalarPrepQuery(query, []) print rc ``` Prints `1` and updates the row in the table. Seeing as it just "Returns the number of rows affected by the last statement" [per the Microsoft Documentation for SQL Server](https://learn.microsoft.com/en-us/sql/t-sql/functions/rowcount-transact-sql?view=sql-server-ver17) it really feels like there's an issue with `runPrepUpdate` in the console context specifically. ---
**Author:** ![pturmel](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/pturmel/32/3295_2.png) [@pturmel](https://forum.inductiveautomation.com/u/pturmel)\ **Post date:** [July 20, 2026, 12:04am UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457/3 "2026-07-20T00:04:03Z")
IIRC, there's a bug in the v8.3 runPrepUpdate if there are no parameters to substitute. ---
**Author:** ![TT-ignit](https://avatars.discourse-cdn.com/v4/letter/t/439d5e/32.png) [@TT-ignit](https://forum.inductiveautomation.com/u/TT-ignit)\ **Post date:** [July 20, 2026, 2:56am UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457/4 "2026-07-20T02:56:29Z")
```python query = """ UPDATE READS_ReportRequests SET [Status] = 'Processing' WHERE 1 = ? """ rc = system.db.runPrepUpdate(query, [1]) print rc ``` Indeed affects a change in the database. I ended up using this pattern instead: ```python query = """ DECLARE @claimed TABLE (ID INT); UPDATE READS_ReportRequests SET Status = 'Processing' OUTPUT INSERTED.ID INTO @claimed WHERE ID = ( SELECT TOP 1 ID FROM READS_ReportRequests WITH (READPAST, UPDLOCK) WHERE Status = 'Pending' ORDER BY RequestedDate ASC ); SELECT ID FROM @claimed; """ result = system.db.runPrepQuery(query, []) ``` Which has the useful side effect of returning the ID of the row I updated anyway, which `getKey=1` does not seem to do. ---
**Author:** ![code\_skin](https://avatars.discourse-cdn.com/v4/letter/c/43a26b/32.png) [@code\_skin](https://forum.inductiveautomation.com/u/code_skin)\ **Post date:** [July 20, 2026, 3:00pm UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457/5 "2026-07-20T15:00:31Z")
I believe this was fixed in 8.3.7. [Ignition Release Notes for Version 8.3.7 | Inductive Automation](https://inductiveautomation.com/downloads/releasenotes/8.3.7#:%5C~:text=Fixed%20an%20issue%20where%20prepared%20statement%20calls%20passed%20empty%20parameter%20arrays%20would%20fail%20to%20execute%2C%20affecting%20system.db%20functions%20runPrepUpdate%2C%20runPrepQuery%2C%20runScalarPrepQuery%2C%20as%20well%20as%20Vision%20query%20bindings). ---
**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:** [July 20, 2026, 4:34pm UTC](https://forum.inductiveautomation.com/t/sql-update-statements-silently-fail-in-script-console/116457/6 "2026-07-20T16:34:18Z")
Correct: > [@\[IGN-15326\]8.3 system.db.runPrepUpdate not throwing](https://forum.inductiveautomation.com/t/ign-15326-8-3-system-db-runprepupdate-not-throwing/113554/11): > > This issue will be fixed in tomorrow's nightly/the full release of 8.3.7.