# Nube can't connect to DB **URL:** \ **Category:** Module Development\ **Tags:** sdk\ **Created:** [July 31, 2018, 7:28am UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029 "2018-07-31T07:28:08Z")\ **Posts on this page:** 10\ **Page:** 2
**Author:** ![anthony.todd](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@anthony.todd](https://forum.inductiveautomation.com/u/anthony.todd)\ **Post date:** [August 5, 2018, 4:31pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/21 "2018-08-05T16:31:20Z")
Hi Kevin, OK… After looking at the differences in how the gateway based and client based modules are configured, It looks like the client based would probably be easier to develop and maintain for the long run. I have converted everything to be client based… I setup the multiply example and got it to compile and run. I am having a bit of a problem working with the ClientDBUtilities though. At least with the gateway based module the DB access was working. I have gotten to the point of just trying anything and everything, and I can’t even get it to the point that IntelliJ quits complaining. A user guide for the utilities would be nice. I have not found one example or explanation of it anywhere. Java Docs aren’t really documentation in my opinion. Would it be possible to give me a full working example of the runQueryPrep and passing in the args? I believe I will be off to the races at that point. Until then, I am busy stubbing out a couple of hundred methods. Thanks, Anthony Todd ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 5, 2018, 5:37pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/22 "2018-08-05T17:37:43Z")
I should have looked closer before suggesting you could use `ClientDBUtilities`. @pturmel mentioning `AbstractDBUtilities` put me on autopilot… All of these utility classes, while they happen to be accessible on the classpath, are not really public API. They are the implementations for our own scripting functions, and that’s why a lot of the method signatures are so obscure looking (because they’re meant to be invoked from Jython using keyword-args). I’m not super familiar with programming in the client scope, especially as a module author. Perhaps using RPC for calls that need database access _is_ the best practice. Accessing DB from the gateway scope is straightforward. ---
**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:** [August 5, 2018, 11:17pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/23 "2018-08-05T23:17:06Z")
Leveraging `ClientDBUtilities` is the best way to maintain security. Otherwise you might be in for surprises, or you’ll have to enforce security yourself. `ClientDBUtilities` also provides the same call signatures that your existing scripts are using, providing a proven conversion path. I wouldn’t dismiss it out of hand. ---
**Author:** ![anthony.todd](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@anthony.todd](https://forum.inductiveautomation.com/u/anthony.todd)\ **Post date:** [August 6, 2018, 11:26am UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/24 "2018-08-06T11:26:07Z")
Hi Phil, I have not dismissed it, in fact this is exactly what I have been trying to do, I just can’t seem to make it work. Despite the fact that it has the same calls, they are not implemented in a similar manner. I really do need a full working example of how to implement at least one of these calls, including passing the args. The two calls I know I will need for sure are runUpdaateQuery and runQueryPrep. This appears to be the only thing I am missing at this point. Thank You, Anthony Todd ---
**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:** [August 6, 2018, 6:05pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/25 "2018-08-06T18:05:24Z")
The jython call model is really generic. Two arguments are passed: an array of PyObject arguments, and an array of String keywords. The keywords supplied align with the trailing PyObjects. Functions that don’t accept keywords will throw an exception if the latter array isn’t empty. The rest of the arguments are positional. For example, see these signatures from AbstractDBUtilities: ```auto public Integer runUpdateQuery(final PyObject[] pyArgs, final String[] keywords); public Integer runPrepUpdate(final PyObject[] pyArgs, final String[] keywords); ``` In your script module, you will need to instantiate it with the client context, and create an instance of ClientDBUtilities in your constructor. Then the methods exposed to your users can call the utilities like so: ```auto public Integer indirectPrepUpdate(PyObject query, PyObject args) { return myClientDBU.runPrepUpdate(new PyObject[] { query, args }, new String[0]); } ``` If you want your methods to handle keyword arguments, too, you’ll have to pluck out the ones that are meaningful to you, and repackage just what the client DB utilities want. ---
**Author:** ![Kevin.Herron](https://sea1.discourse-cdn.com/inductiveautomation/user_avatar/forum.inductiveautomation.com/kevin.herron/32/7259_2.png) [@Kevin.Herron](https://forum.inductiveautomation.com/u/Kevin.Herron)\ **Post date:** [August 6, 2018, 7:11pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/26 "2018-08-06T19:11:37Z")
> [@pturmel](#): > > Leveraging ClientDBUtilities is the best way to maintain security. Otherwise you might be in for surprises, or you'll have to enforce security yourself. My understanding is that he simply needs to be able to make database calls to implement some of his scripting functions, not re-expose `runUpdateQuery` and `runPrepQuery`. The only "security" he's inheriting by using `ClientDBUtilities` is the whether legacy queries vs. named queries are allowed, and this is arguably a _bad_ thing in his case, because if the project is set up so only named queries are allowed all his database calls through `ClientDBUtilities` will start failing... @anthony.todd maybe you can clarify here... ---
**Author:** ![anthony.todd](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@anthony.todd](https://forum.inductiveautomation.com/u/anthony.todd)\ **Post date:** [August 6, 2018, 9:23pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/27 "2018-08-06T21:23:48Z")
Sorry for the delay guys, I live in Belgium, so I just got back from visiting family. Yes that is correct I just need to run the same queries that are currently being run from Python. Nothing fancy, I am simply encapsulating the existing python functions as methods in a module. These functions all have queries contained in them. I want to keep it as straight forward and easy to maintain as possible. It will have to be maintained for many years to come. Thanks, Anthony Todd Going to bed now, I’ll check in the morning 🙂 ---
**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:** [August 6, 2018, 11:29pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/28 "2018-08-06T23:29:50Z")
> [@anthony.todd](#): > > I want to keep it as straight forward and easy to maintain as possible. It will have to be maintained for many years to come. Well, that's a good argument for switching to named queries. I'd still go through ClientDBUtilities to execute the named queries (with the corresponding methods). ---
**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:** [August 6, 2018, 11:46pm UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/29 "2018-08-06T23:46:17Z")
> [@Kevin.Herron](#): > > not re-expose runUpdateQuery and runPrepQuery. My example was intended to be a bare-bones syntax "how-to", not fully functioning code for his case. Anthony's wish for a "full working example" is unlikely to come true. Sorry, Anthony. ---
**Author:** ![anthony.todd](https://avatars.discourse-cdn.com/v4/letter/a/5fc32e/32.png) [@anthony.todd](https://forum.inductiveautomation.com/u/anthony.todd)\ **Post date:** [August 7, 2018, 5:18am UTC](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029/30 "2018-08-07T05:18:44Z")
Hi Guys, I really see no advantage in switching to named queries. As stated earlier, I just want to encapsulate the existing scripting in a module. I do not understand why this has to be so hard. @Kevin.Herron can you send me a mail? I would like to share some things with you that I do not want posted on an open forum. My email [anthony.todd@ats-global.com](mailto:anthony.todd@ats-global.com) Thanks, Anthony Todd [Previous page](https://forum.inductiveautomation.com/t/nube-cant-connect-to-db/19029.md?page=1)