Sqlth_te Duplicates BUG

I have a problem with the duplicates created by the Gateway into the sqlth_te table. If I edit a tag with Historian on it will create a new instance of the tag in the DB every time the value changes.
The only way to stop this behavior is to stop and start the gateway. If left unchecked it will not stop, meanwhile it is NOT logging to the sqlth_1_data table for this tag. I went to the beta 4 version as suggested in the forum but it has not corrected the issue.

Your assistance here would be greatly appreciated as I do not have a work around for editing the tags without this problem. I reference the sqlth_te table and need it to be accurate and not filled with incorrect id’s and path references.

V = 7.5.4-beta4
This is 24 hours of duplicates:
Tagpath Duplicates
site/rcv/a/ln/cd/_outs/out1 2600
site/flt/srt/ch/f74/full_timer 2408
site/rcv/a/ln/ef/_outs/out1 2366
site/rcv/a/ln/ab/_outs/out1 1818
site/mod/b/srt/mrg/_outs/out1 1524
site/flt/srt/ch/f33/full_timer 1268
site/mod/b/srt/mrg/_ins/in1 1198
site/rcv/a/ln/tshp/_outs/out1 1020
site/flt/srt/ch/f27/full_timer 816
site/flt/srt/ch/f34/full_timer 744
site/flt/srt/ch/f36/full_timer 512
site/flt/srt/ch/f38/full_timer 484
site/flt/srt/ch/f79/full_timer 420
site/flt/srt/ch/f21/full_timer 368
site/flt/srt/ch/f69/full_timer 342
site/flt/srt/ch/f28/full_timer 202
site/flt/srt/ch/f32/full_timer 168
site/flt/srt/ch/f78/full_timer 164
site/shp/srt/_outs/out34 136
site/flt/srt/ch/f81/full_timer 108


Could you perhaps send me the results of the most recent 10 or so entries for tagpath “site/rcv/a/ln/cd/_outs/out1”? The system looks at several parameters and inserts only if they don’t match. Looking at the most recent entries will hopefully help me track down where the problem is occurring: either some parameter is changing each time, or the system is not properly caching the recently created id, and the check is failing each time.

Also, you said that it is not logging to the data table for the tag during this time- could you check the count and most recent timestamp for tag id 0, and see if it might be logging under that? The tag id record is inserted with a special “run insert, get key” command that returns the generated id for the tag. If this command failed to return the correct key (and returned null, for example) the data would be stored under that. Along this line, which database system are you using?