Initially just makes things more puzzling, though it should be another clue to what's going on.
The message id field here is an identity field, so the only way I can think of that *might* cause skipping is two concurrent writes with one of them failing. Maybe. I would think the successful one would grab the number and the failed one wouldn't be able to.
I'm definitely going to have to use try/catch in the post_info proc and at least log the errors to see what's going on. Though the main idea is to prevent the errors from happening in the first place, have to identify the errors first, though I'm nearly 100% positive that locking/concurrency issues are preventing the message insertion from happening. At times. Looking like about 1% of the time, which is way too high.
Edit: I put the TRAN wrapping back around the message insertion proc, which I'm pretty sure will at least prevent the msg number gaps. I think those are getting caused by the insert failing but the updates, including board msg count, which is used for intra-board numbering, aren't failing. With the TRAN wrapper, one item fails, they all fail and are rolled back.
Though I do need to check to make sure this version of SQL will automatically roll back on failure and I don't need to explicitly tell it to do so.
