I noticed also this message on PcVue startup (sometimes).
Is it your case?

I think the issue is coming from the exit of PcVue. HDS is supposed to flush its buffer but, for an unknown reason, it keeps those data (already recorded) in a file.
Then, on startup , HDS finds this file and tries to record again the same data => Primary Key violation.

As your customer is using an old version I suggest you check with Arnaud if this anomaly has been already fixed.

There are 2 kinds of problems that could occurs

First, which kind of timestamping are using ? PLC or SV ?
If it's PLC one, then at startup this kind message appears if variables has not changed between stop and start. Same thing for a comm failure.

Second, in the case of replication, the same thing could happen if some datas has already been recorded in one server and not yet in the other one. Then when the second server try to record the datas, the replication has already done the job. As both servers have the timestamp for a value, its origin (SV or PLC) doesn't matter.

HDS records datas when there is at least a packet of 15 records or every 15s. As replication is faster than HDS, as soon as a server record a data the replication will replicate it in the other server before it does the job by himself.
Try to reduce replication step to 1mn, you should have less error messages.

First, which kind of timestamping are using ? PLC or SV ?
If it's PLC one, then at startup this kind message appears if variables has not changed between stop and start. Same thing for a comm failure.

Good Point! I really see anomalies every where ! :whistle:

Second, in the case of replication, the same thing could happen if some datas has already been recorded in one server and not yet in the other one. Then when the second server try to record the datas, the replication has already done the job. As both servers have the timestamp for a value, its origin (SV or PLC) doesn't matter.

HDS records datas when there is at least a packet of 15 records or every 15s. As replication is faster than HDS, as soon as a server record a data the replication will replicate it in the other server before it does the job by himself.
Try to reduce replication step to 1mn, you should have less error messages.

Does it mean that usually, when we use replication, the replication period is less than 1 mn?

Additionnaly they launch a replication every 10s.

That's François' customer who do that 😉

Usually replication periods are 1hour, half-day, day and sometimes week or 10mn. It's the first time a see so fast replication !

Thx guys for your ideas
Actually they use OPC only
I'm also surprised by the frequency of the replication, and it's probably the reason if these messages.
These messages are not so frequent so it should not be an issue

Some additional info about error 4097 (since this is the only indication about this issue that you see with default traces activated):

Error code 4097 is Integrity database violation as key violation
It’s a mixed value with a mask 4096 + 1 (0x1001).

adRecIntegrityViolation	0x1000	Record not saved; user violated integrity constraints
adRecNew	0x1	Record is new

To summarize possible reasons for that error message:

• Servers in a single-active-server historical association don't see each other (and therefore assume that they are both active).
• Replication.
• Timestamping at source with bad clock synchronisation.
• To be confirmed: Usage of svMgrVarEnum. In the case that I am currently investigating it seems to me like the issue is caused by a miscalculation of a value's timestamp in the svMgrVarEnum under certain conditions (details still unclear). If you have seen this effect already, please drop me a small note.