That should no longer be happening as of yesterday afternoon.
Long version for those who like the geek details...
I finally had it happen to me, so I was able to dig in and see all of the details of what'd happened.
When you write a public message, it being inserted into the database is handled now by a single procedure that's wrapped in a transaction.
10 lines later in the ASP, a separate query is issued that finds the message_id of the last message you wrote. What happened in my case, and I'm sure you'll find happened in your case, is the message_id that the query returned and the system tried to redirect you to was that of a PM you wrote. That results in the "No Such Board" error. Similarly, if the last previous message you wrote wasn't a PM, I suspect the system would take you to that message instead of the one you just wrote.
It's been a bit of a puzzler. Largely academic at this point, as I changed the 10-lines-later query yesterday to read uncommitted data (data that the system thinks is still in the process of being written to disk), so that problem should quit happening.
What's been puzzling me is that 10 lines later in the ASP, what happened 10 lines up actually hasn't *finished* happening. If it had, the message_id of the message you just wrote would be the one returned in the 10-lines-later query.
It's like the webserver is getting ahead of the database server somehow.
A real head-scratcher.
It was suggested that in the message-insertion query I just grab the message number of the new message and hand it back to ASP, but I think that would likely make the problem worse. Because if the new message didn't "exist" 10 lines later, why would it exist only 2 lines later?
I'm going to try it, though. Because one factor might work in its favor.
The time it takes to pull off the redirect (load user data, the top menu, and grab the message), while extremely small in human terms, is an eternity in computer terms, and might be long enough for the new message to finally "exist".
But it's going to bother me and I'll be obsessed with finding the answer, because a committed transaction should "exist" immediately afterwards. Not a few milliseconds later.
