The Microsoft SQL (Insert) node fails because the DB is down, but it returns success. Is this a BUG? Or do I need to do some different configuration on the node?
Hello @Robson
I think that node currently does not support the error ouput. That feature has been implemented quite recently and not every node support it.
@Jon maybe you should consider to disable that feature by default for services, that haven’t tested against it? Or add a warning message that it might not work
Hello @barn4k ,
Thank you so much for your reply!
Is there any way to know that my INSERT has failed?
Because in these cases I want to generate a JSON file for further processing, when the DB comes back.
Yes, I’ve tried this and failed.
How can I check Microsoft SQL node error on next node?
Can you please give me any tutorials or examples?
I do not have an SQL, but the logic will be the same
Hi @barn4k
It still doesn’t work, even if we follow your suggestion.
Could it be that it’s a SQL node BUG, which can’t pass the json.error forward?
In this example with error in SQL node the database is down. But I did another scenario where the table name is wrong and the SQL node doesn’t generate an error and executes successfully, i.e. it doesn’t detect that the table doesn’t exist.
I updated my n8n on version 1.42.1, but the BUG continues.
Can you help me? Please…
Thanks,
Robson Liima
I have the same problem, I didn’t find a reliable workaround.
Hi @Robson
In version 1.44.1 of n8n, a new version of the sql server node was made available, version 1.1 (the previous one was 1.0), and in this version of the sql server node, this problem was properly resolved.
You are not seeing this behavior, as I did not realize that the node you have a problem with must be removed and placed back into the workflow so that the new version of the node can be used.
You can see what I’m talking about if you check the footer of the “Settings” tab of the SQL Server node.
I’m also facing the same issue. “On Error: Continue” and “On Error: Continue (using error output)” options are not working.
As mentioned in other threads the node is also not running through all items.
And I believe the “Insert” operation is not working either (guessing that’s why @Robson is not using it).
Would be nice if n8n team would take care of fixing all these issues with this node. In my opinion it should work as the Postgres node works.
Hello @Fortian
As I said above, version 1.1 of Node SQL Server fixes the problem of handling the execution flow after an error. When you mention “running through all items” for the insert command of node SQL Server, it would not be the situation that is documented in this point ?
If so, this is not a bug, it is that way by design.
Hola Victor,
Thanks for your answer! I missed your message about version 1.1, I hope we will upgrade soon so that we can take advantage of it.
Regarding the “running through all items” point, it’s indeed documented in the link you have shared but I can’t understand why we have such “n8n exceptions”. Postgres node behaves according to n8n standard concept of the node running for each item, I wonder why we can’t do the same with Microsoft SQL.
And regarding the “insert” operation, I didn’t manage to make it work so I had to go with the “Execute query” operation, which I think is a pity.
Hi members,
I updated SQL node version 1.1 and it still doesn’t work. I put the database on shutdown and the SQL node detects the error but doesn’t move forward.
t{
"meta": {
"templateCredsSetupCompleted": true,
"instanceId": "ea65200d7c856ec9da568f2fcb224d670b7a42675ff37f7f1d715f88cd260414"
},
"nodes": [
{
"parameters": {
"table": "USUARIOS",
"columns": "NOME, LOGIN"
},
"id": "d65470af-11a8-4fd4-aa5c-c65146911ec0",
"name": "Microsoft SQL",
"type": "n8n-nodes-base.microsoftSql",
"typeVersion": 1.1,
"position": [
-840,
540
],
"alwaysOutputData": false,
"credentials": {
"microsoftSql": {
"id": "1skpWfwmaUFGOZF6",
"name": "Microsoft SQL account"
}
},
"onError": "continueRegularOutput"
}
],
"connections": {},
"pinData": {}
}
Yes, it would be cool if nodes related to the same subject (in this case, relational databases) behaved in the same way regarding n8n’s mechanisms, but I imagine that some technical reason may have led the developer to add this exception. Regarding “insert” option on the SQL Server node, it is not very intuitive, however, I think it works (I use it in some workflows), in the parameters, it requests the table, and a list with the name of the fields in which the insertion should occur , and at that moment, the node uses the value of the variables in the $json object that have the same name as the table field.
I noticed that, in the SQL Server node, you configured the “On Error” option as continue, and in the print screen of the Workflow Editor, the Error was reported in the sql server node, and the execution continued (green line after the sql node server , connecting to the IF type node). I think this is the expected behavior, after all, when an error occurs, the process “continued”, if you want, in addition to the fact that when an error occurs, the processing flow of the workflow, may take a different direction than normal, you have to put the value “Continue (Using Error output) in the “On Error” option of the SQL Server node”, this will make the editor offer two “outputs” from the node SQL Server, an output for when the operation is executed successfully (the output that already exists in your flow), and another output for when the execution of the node in question runs with an error.