# SQL Tag Deadlock Recovery **URL:** \ **Category:** Ignition\ **Created:** [March 24, 2021, 2:29pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855 "2021-03-24T14:29:48Z")\ **Posts on this page:** 7\ **Page:** 1
**Author:** ![gfeiten](https://avatars.discourse-cdn.com/v4/letter/g/cdc98d/32.png) [@gfeiten](https://forum.inductiveautomation.com/u/gfeiten)\ **Post date:** [March 24, 2021, 2:29pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/1 "2021-03-24T14:29:48Z")
I have a SQL tag that updates every 5 minutes. It takes about 5 seconds to run. Every 2 or 3 days we will get a deadlock error and lose the tag value until I manually intervene to cause it to execute the query again (usually by opening the tag in the browser and saving it again, or disabling it/reenabling it.) Is there a way to put something along the lines of a try/except in the SQL driving the tag? I would like it to retain the previous value until the query runs successfully again. Not a big deal if we miss an update every couple of days. Thanks! ---
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [March 24, 2021, 2:46pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/2 "2021-03-24T14:46:24Z")
What type database are you talking to? MS SQL does have [Try/Catch](https://docs.microsoft.com/en-us/sql/t-sql/language-elements/try-catch-transact-sql?view=sql-server-ver15) functionality in SQ as explained in this [example](https://docs.microsoft.com/en-us/previous-versions/sql/sql-server-2005/ms179296(v=sql.90)) I’m not sure about other DB brands. But I am curious to know why you are getting deadlocks on something that I assume should only be read functionality ---
**Author:** ![gfeiten](https://avatars.discourse-cdn.com/v4/letter/g/cdc98d/32.png) [@gfeiten](https://forum.inductiveautomation.com/u/gfeiten)\ **Post date:** [March 24, 2021, 4:23pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/3 "2021-03-24T16:23:15Z")
It’s a SQL Server 2000 database. Besides being extremely old the design probably isn’t very good. ---
**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:** [March 24, 2021, 5:59pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/4 "2021-03-24T17:59:28Z")
Use a gateway timer script writing to a memory tag. Failures in the query won’t disturb the current tag content. ---
**Author:** ![peter](https://avatars.discourse-cdn.com/v4/letter/p/278dde/32.png) [@peter](https://forum.inductiveautomation.com/u/peter)\ **Post date:** [March 24, 2021, 8:40pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/5 "2021-03-24T20:40:37Z")
That’s an old DB. Forget what I said about the SQL transactions. From what I understand they are only 2005 onwards ---
**Author:** ![adnaram](https://avatars.discourse-cdn.com/v4/letter/a/bc79bd/32.png) [@adnaram](https://forum.inductiveautomation.com/u/adnaram)\ **Post date:** [March 24, 2021, 9:12pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/6 "2021-03-24T21:12:39Z")
You might use the WITH (NOLOCK) to prevent deadlock. Ex. SELECT \* FROM Person.Contact WITH (NOLOCK) ---
**Author:** ![gfeiten](https://avatars.discourse-cdn.com/v4/letter/g/cdc98d/32.png) [@gfeiten](https://forum.inductiveautomation.com/u/gfeiten)\ **Post date:** [March 25, 2021, 12:17pm UTC](https://forum.inductiveautomation.com/t/sql-tag-deadlock-recovery/44855/7 "2021-03-25T12:17:30Z")
Thanks for all the suggestions! =\> Peter: I spent a good part of an hour trying to figure out why I was getting syntax errors on the Try/Catch before figuring out SQL 2000 didn’t support it. ☹ Fortunately the DB is scheduled to be updated in the coming months. =\> Phil: I think I may implement your suggestion even if I can resolve the deadlocks, just as a safety measure. =\> Adnaram: I have been trying to educate myself on the pros and cons of NOLOCK. I don’t think dirty data would be much of an issue with my application. I think I am going to try to modify the query to incorporate temp tables instead of all of the nested querying to reduce the chances of a deadlock condition. Pretty sure I will solve this one way or another, thanks again for the suggestions!