Violation of Primary key Histo

Hello,
I have this error java.sql.BatchUpdateException: Violation of PRIMARY KEY constraint 'PK__sqlt_dat when I restart my opc connection in production or when the trial in demo restarts, I don't know if it's due to a bad setting of the history at the tag level or other things?
When I check in the histo database the id of the tag in the error with the timstamp and the value is already present in the database, I delete the latter from the database but when restarting I still have the same error

Run a query on PK__sqlt_dat to return the count of each key and order by key descending. There should only be one of each.

When I export the quarantined file, I have all the histo tags in the xml file

So, do you have any duplicates in the primary key1 column?

1 A primary key should contain an integer unique to that row. It can be used to uniquely identify a row and for indexing purposes to greatly speed up queries.

Yes all the export data of the XML file, is already in the Histo database, so duplication of primary kay, because the tagid has the same value and timstamp as in the database.
but I don't know why, every time there is an insertion in the database even if it's already hitorized in the screen
No need for chatGPT answer please !

If they are already in the _HISTO database then you can delete the quarantined file.

I don't use ChatGPT, thank you!

3 Likes

I don't want to delete the quarantined 20 times a day, I think there's a mistake somewhere

You'll need to provide more information about how the tag(s) is set up, and where it originates. (e.g. are you using Ignition's OPC server is there a third party server involved.) Are the gateway and database on separate servers? If not are the two servers set to the same Date and Time format and Location?

Honestly the only ways I've seen the historian give a primary key collision is when there is a discrepancy in the date and time of where the OPC Server is and where the Database is. Or when history is being manually inserted via script.

1 Like

The tags that cause problems are the opc tag, collected via a KEPServerEX, for The database, yes it's in another machine.
The history is not manual, there is no script or another part for historization.
Thanks for the help.
but I don't understand that this only happens if there is a connection after a loss of connection with keep !
Are there any leads on the subject