I am having trouble with 'node-red-contrib-mssql-plus' and others when it comes to connecting and working with multiple databases. There is a documented bug. There is no response from the owner of the node.
The problem began, possibly, on the advancement of 'node-red-contrib-mssql-plus'... I upgraded to the newest version some months ago. I was hoping to revert back to a prior version, if possible. I installed 'node-red-admin' which may allow an alternate installation tool through command line. Am I barking up the wrong tree? Perhaps.
I was looking at the documentation on 'node-red-admin' and it's not enough to answer the question of installing a back dated version of 'node-red-contrib-mssql-plus'.
Is it possible to install a back version of any node? Did I miss it in the documentation?
Colin,
Thanks, Apparently 'node-red-admin' is limited to use as a remote tool. Since Node-RED editor has an installation dialog for the palette, I was wondering if the command line version had more functionality than the Node-RED dialog, (no options on installing nodes) and node-red-admin was preferred over 'npm' command line.
I could not find much on documentation on 'node-red-admin' other than a list of 'commands'.
I have had some issues in the past where I installed a node and then it could not update from the Node-RED palette dialog. I've had to uninstall and re-install using the Node-RED palette in order to have future access to "updates".
As long as you don't use root or install globally (-g) then it should be the same as using the built in manage palette. Only that doesn't let you pick versions. If you look at the log (when using the manage palette) you can see the command it is running.
As it turns out, the root (of the original) problem has to do with ES6 and the Modules being cached. link to stackoverflow.com.
"Two key elements are at play here.
Modules are cached after the first time they are loaded. This means that every call to require('./db') will return exactly the same object. The first require of db.js will run that file and create the promise and export it. The second require of db.js will return THAT same promise without running the file. And it's that promise that will resolve with the pool.
A promise can be thenified again. And if it resolved before, it will immediately resolve again with whatever it resolved with the first time, which is the pool."
The installation of any older node isn't the solution. it's actually NodeJS. What we need to do is update the current MSSQL nodes (or have the author update...) behavior to force initialization of the connection each time you open a connection to another server.
Nick,
The cache referred here isn't installing a node. Installing an older working one was only a guess at resolving the main problem with MSSQL. its ES6 caching the configuration data used in a sql connection. If you connect to another database... then establish a once connected, other database, it uses the cache configuration data, thus generating errors because the expected tables and configuration now don't match.
Believe me, I always re-start Node-RED on installing any nodes.
Just want to extend some thanks - your comment here, along with others over on GH saved my sanity when the latest version of node-red-node-serialport sent my dockerised RPi instance into a reboot loop.
