After completing the SQL Query and then setting the properties for an input, I cannot click the finish button without getting the following error:
There was an error processing your request. It has been logged (ID 7af858e1614ada9e).
If I click on it again I get a different ID. Tried going through the logs, did not see anything pointing to why it won't complete the process.
Anyone else get past this?
More info:
Using DBConnect 3.1.1 build 34
Connecting to a Microsoft SQL DB using MS-SQL Server Using MS Generic Driver. Host verified and port verified on connection.
SQL query executes successfully.
We were able to get this to work through the backend and entering the same query into the backend db_inputs.conf \etc\apps\splunk_app_db_connect\local\
Am having similar issue, please did you ever get any solution on this issue? Another concern is that i upgraded Splunk to 8.1.1 and db connect to 3.4.2. I have a data connection that is point to MS generic driver. please can i have a url that i will get that drive from as well?
Vi into db_inputs.conf, add new input along with query and save, then I restart Splunk, log back into the UI and the new input should show up. Hope this helps
This worked for me too.
I was getting this when i was trying to install the Microsoft SQL Server
driver:
https://docs.microsoft.com/en-us/sql/connect/jdbc/download-microsoft-jdbc-driver-for-sql-server?view...
As described here:
https://docs.splunk.com/Documentation/DBX/latest/DeployDBX/Installdatabasedrivers
When using the v13
and v11
JAR files, I got this error. However, when I used the v8
JAR, I did not get any errors and it showed up correctly on the drivers screen.
Thanks, this helped me when I faced the same issue
Hey all is this a known error
Hi everyone, If someone knows, was this bug fixed? If it isnt fixed, ill have to use the work around on my enviroment.
Thanks for the work arround, @bradob .
It is not fixed. Does this surprise anyone?
Hello @nick405060
If the problem is about your connections in hosts in splunk db connect you should search if there is the same stanza in other db_connections.conf. can you check if you have twice stanza.
We were able to get this to work through the backend and entering the same query into the backend db_inputs.conf \etc\apps\splunk_app_db_connect\local\
My team was able to get this to work through the backend, too. Another thing to add here is that I kept getting this error when my SQL query started with "EXEC." When I asked the user for a query that started with "SELECT" because most of our other queries start with that, I stopped getting the error and it worked. I do not know enough about SQL to speak to the significance of this difference, but this is the behavior we are seeing. Splunk seems to take EXEC on the backend but not in the UI, and SELECT in the UI works.
I manually created
the db_inputs.conf file
but it does not run😓
what should i do?
Vi into db_inputs.conf, add new input along with query and save, then I restart Splunk, log back into the UI and the new input should show up. Hope this helps
I had the same problem and managed to bypass it by editing the configuration file.
I still do not know why it does not save the page, but editing the file directly through linux works fine.
@bradob, if this worked for you, please accept the same as answer to mark this question as answered.
I had the same issue with DBX v3.1.3 with MS SQL query setups in the GUI:
ERROR ... Error handling a request:
...
Caused by: java.lang.NullPointerException: null
at com.splunk.dbx.server.util.ResultSetMetaDataUtil.isTableHavingSameNameColumns
I updated the configurations on the back end and they work fine.
This should be considered a workaround / bug that should be corrected in DBConnect
@bradob, you should mark your question with BUG
tag. Also reach out to Splunk Support if you have Splunk Entitlement. However, I feel this issue might be just impacting you.
Java version : 1.8.0_152-b16
I have exactly the same issue.
However the "Answer" / Workround below is not permitted in my environment as I do not have shell access to the server.
Please can we raise this as a bug in dbConnect - since if the SQL parses then the connection etc is valid.