-
Hi, Many of our interfaces are either SQL database readers as a source or connect to SQL to import in our destinations. In all of these channels, we use a SQL account and specify either the username/password in the GUI (for a database reader/destination) or if we use a javascript step, we build out the jdbc connection string and hardcode the username/password. I was just curious as to what others do or if they are using some other process or somehow using an AD account instead of a SQL account and having all the Mirth channels run under that AD account without having to specify usernames/passwords in the channels? The reason I ask is because the SQL account we are using in all our channels is having the password changed and we know need to go through all the interfaces and update it manually, then redeploy. Is there any easier way to do these connections without having to go through this again in the future? Thanks in advance, |
Beta Was this translation helpful? Give feedback.
Replies: 2 comments 1 reply
-
https://github.com/pacmano1/Mirth-Snippets/blob/main/executeSharedDBStatement.js However we always use db readers in JS mode. Also, that does a single shared connection in $g, you can certainly modify that as you see fit for more "pooled" connections. There are other solutions of course. |
Beta Was this translation helpful? Give feedback.
-
Awesome! This is what I needed, thanks. |
Beta Was this translation helpful? Give feedback.
https://github.com/pacmano1/Mirth-Snippets/blob/main/executeSharedDBStatement.js
However we always use db readers in JS mode. Also, that does a single shared connection in $g, you can certainly modify that as you see fit for more "pooled" connections. There are other solutions of course.