Quote from: LoyceV on May 25, 2018, 08:37:41 AM

I checked all time stamps, and they all show up in this weeks's data file.

Thanks, I think I know what's going on with them:

time amount msg user_from user_to
1526466697   1   4097266.msg37354230   1192397   209286
1526427398   1   4075132.msg37378125   452769   1168027
1526417463   1   3979143.msg37390368   1160524   1012481
1526412210   1   4075132.msg37378125   1627661   1168027
1526403535   2   4032536.msg37344086   234915   501852
1526391452   2   4032536.msg37344086   1765178   501852
1523884328   2   4169555.msg34758186   974425   668651
1518181690   1   4029745.msg29300364   1141229   1495332
1518181563   1   4029745.msg29300364   1141229   1495332

The timestamp is in the current file as you say, but the messageID has changes from one file to the other. The first record (4097266.msg37354230) still exists and reading the post seems to have moved section. The remaining 8 are now deleted (propably after moving them first).

I'm using as a conceptual PK all the fields in the record, not just the time, therefore showing those records in the new file as non-existant in relation to last week's file.

I checked and there are 499 cases of timestamps with 2 or more associated TXs in the file, therefore going for the complete record PK.

Edit:
What this entails is that changes to records older than 120 days may not be consistent in our ALT aggregate databases.
For example, as seen above, some merited TXs may change section or get deleted, but the ALT aggregate database will still point to the original message once the TX is outside of the 120 window frame.

It should be a minor issue, since in a week only 9 awarded Txs have suffered a change of associated message Id. Just a bug for accuracy, but not a problem on the whole.