# Run queries on gateway config DB

**URL:** <https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450>\
**Category:** Ignition\
**Tags:** database, scripting, ignition81\
**Created:** [January 27, 2025, 9:05pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450 "2025-01-27T21:05:14Z")\
**Posts on this page:** 14\
**Page:** 1

<div class="post-metadata">

**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\
**Post date:** [January 27, 2025, 9:05pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/1 "2025-01-27T21:05:14Z")

</div>

Hey, all --  
I'm looking to run queries (both read and write) over the ignition config DB while the gateway is running (both to grab/copy valid sessions, to check tag config changes, and some other things). Is there a guide out there to how to connect to the in-mem DB or SQLite file that ignition uses as its db by default?

---

<div class="post-metadata">

**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\
**Post date:** [January 27, 2025, 9:09pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/2 "2025-01-27T21:09:09Z")

</div>

I believe the internal db is limited to a single connection (that is used by Ignition). You can get the majority of data from this db using the built in system functions of Ignition.

> **[System Functions | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/appendix/scripting-functions)**
>
> The Ignition scripting API, which is available under the module name system, is full of functions that are useful when designing projects in Ignition. From running database queries, manipulating components, to exporting data, scripting functions can...

There is also additional information you can get if you look through the SDK documentation.

> **[Overview](https://files.inductiveautomation.com/sdk/javadoc/ignition81/8.1.44/index.html)**
>
> package index

---

<div class="post-metadata">

**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:** [January 27, 2025, 9:15pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/3 "2025-01-27T21:15:15Z")

</div>

In addition to having a high risk of locking up your gateway, all of this is going away in v8.3, right around the corner. Consider **not** wasting your time on this. Use the `system.*` APIs--those don't disappear across major version changes.

---

<div class="post-metadata">

**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\
**Post date:** [January 27, 2025, 9:28pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/4 "2025-01-27T21:28:45Z")

</div>

Sure, these session APIs generally make sense to me and it's good to hear they're crossversion stable. I do notice that a number of these properties have getters but _not_ setters (e.g. util.session), is there a way around that?

---

<div class="post-metadata">

**Author:** ![ryan.white](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/ryan.white/32/73193_2.png) [@ryan.white](https://forum.inductiveautomation.com/u/ryan.white)\
**Post date:** [January 27, 2025, 9:36pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/5 "2025-01-27T21:36:15Z")

</div>

Certain things are read only by design. You shouldn't ever be trying to set something like session info from the outside. What is your end goal by writing to these?

---

<div class="post-metadata">

**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\
**Post date:** [January 27, 2025, 9:40pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/6 "2025-01-27T21:40:44Z")

</div>

Moving over a user's perspective between multiple gateways (not using ignition redundancy) without losing their session info

---

<div class="post-metadata">

**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:** [January 27, 2025, 9:43pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/7 "2025-01-27T21:43:13Z")

</div>

Good luck.

---

<div class="post-metadata">

**Author:** ![Lynn\_Martineau](https://avatars.discourse-cdn.com/v4/letter/l/f1d935/32.png) [@Lynn\_Martineau](https://forum.inductiveautomation.com/u/Lynn_Martineau)\
**Post date:** [January 28, 2025, 3:18pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/8 "2025-01-28T15:18:14Z")

</div>

Sounds pretty risky.  
Can you get the info you need via WebDev API calls to the other gateways?  
Let each gateway send a response containing their respective Session and/or tag details.

---

<div class="post-metadata">

**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:** [January 28, 2025, 4:27pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/9 "2025-01-28T16:27:47Z")

</div>

To expand a little on Phil here:  
First, session data is not persisted into the SQLite config DB, so your entire approach is flawed. You're going to have to work entirely on the in-memory constructs, using whatever private, undocumented internal methods you can surface.  
Then you're going to have to serialize that session information in some way, package it in a format acceptable to both sides of the negotiation, and send it over the gateway network. Then you're going to have to hope you can manage to fool the receiving gateway in _just_ the right way such that the incoming redirect you trigger from the outgoing gateway happens to line up with your newly received and injected session, and thus that recycled session is used instead of a new session being generated.

Every step of that process is going to be undocumented swimming against the tide, and is right on the edge of being a serious security risk, as a bonus.

The **dramatically** easier thing to do would be to find or create an IdP (not Ignition's) that allows you to persist sessions between gateways, such that the authentication attempt from one gateway is considered valid (by the IdP) on the additional gateways.

---

<div class="post-metadata">

**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\
**Post date:** [January 28, 2025, 4:39pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/10 "2025-01-28T16:39:34Z")

</div>

Oh, this would absolutely work for me. Where is documentation on the IDP system?

---

<div class="post-metadata">

**Author:** ![dillon](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/dillon/32/81537_2.png) [@dillon](https://forum.inductiveautomation.com/u/dillon)\
**Post date:** [January 28, 2025, 4:40pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/11 "2025-01-28T16:40:02Z")

</div>

[Identity Provider Authentication Strategy | Ignition User Manual](https://www.docs.inductiveautomation.com/docs/8.1/platform/security/identity-provider-authentication-strategy)

---

<div class="post-metadata">

**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\
**Post date:** [January 28, 2025, 4:41pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/12 "2025-01-28T16:41:47Z")

</div>

Thank you! And this would allow for Session transfer as well? (The auth flow seems to imply that even if the user is logged in, they would need to repass through auth)

---

<div class="post-metadata">

**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:** [January 28, 2025, 4:42pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/13 "2025-01-28T16:42:48Z")

</div>

Whether the user needs to reauthenticate is a decision made by the identity provider. In the default, entirely-in-Ignition case, that's true. By contrast, think of e.g. a website that supports "Sign in with Google" - you don't have to reauthenticate your Google account each time, the website just defers to Google and Google 'knows' you're still authenticated.

---

<div class="post-metadata">

**Author:** ![Leor\_Fishman](https://avatars.discourse-cdn.com/v4/letter/l/e19adc/32.png) [@Leor\_Fishman](https://forum.inductiveautomation.com/u/Leor_Fishman)\
**Post date:** [January 28, 2025, 4:44pm UTC](https://forum.inductiveautomation.com/t/run-queries-on-gateway-config-db/101450/14 "2025-01-28T16:44:44Z")

</div>

Terrific, thank you.
