I’m having an issue with one of my tags where I am unable to display more than 3 days of historical data on an easy chart in vision. Screen shot below shows the component turns red when doing so.
I also see the following message logged:
com.microsoft.sqlserver.jdbc.SQLServerException: The incoming request has too many parameters. The server supports a maximum of 2100 parameters. Reduce the number of parameters and resend the request.
Any thoughts on how I can fix this???
Did you ever resolve this? Getting a similar issue in the logs and wondering how you fixed it...
Are you querying many tag paths? Are they created/retired often? You might need to get with support to audit your historian DB; it seems like there might be an issue with sqlth_te leading to excessive records (and thus, excessive conditions in the ultimate query being used to return historical data), or some other issue with the historian that support should be able to help with.
Don’t know if this was solved, but I came across a similar issue and found the problem was my server, Ignition program, and Vision client were set up for different time zones. I found out after one of the operators right clicked on the chart, went to Mode, and clicked X-trace. After a moment, a box in the lower left corner showed 12/31/65, 6:59:59 PM, and the time wasn’t changing. The server was set to US-Eastern while the project and client were US-New York. You would think it wouldn’t matter, but they started working the moment I changed them to the same timezone. My guess would be that the server or device controlling the time started drifting to the point that the database started to get screwed up, but I don’t know for certain. Maybe somebody else can provide better insight.
Interesting. The 2100 parameter limit I have seen before from the Microsoft SQL JDBC Driver. I have only ever seen it when trying to run a dynamically sized prepared statement inserting hundreds of rows with 20 columns.
I could see prepared statements being used in the background for the historian, but I can’t come up with a good reason that the time zone not matching would make it exponentially grow the number of parameters for the prepared statement.
It's going to be something that's lead to the creation of too many tag id records in the sqlth_te table. I'm not sure exactly why the timestamp led to the issue, but the reason we use sqlth_te is to automatically 'bridge' across changes to tag configuration, so you'll get a query that's basically select value from data_table where id in (firstPossibleId, secondPossibleId, ...)
If you are regularly writing to tag configuration (either with system.tag.configure() or by direct writes to non-value tag properties) you are restarting your tags often. Tag reconfiguration often makes new entries in sqlth_te.
Are your using scripts that alter tag configuration based on device connection behavior?
