At home the font in the posting box is miniscule and Courier.

Huh. Yesterday I cut and pasted a few lines from a post into an email and it kept coming up that way and resisting all attempts to change it. I finally had to paste into Word, strip the formatting, reset the font and text size, and then repaste into Outlook. Wherever that Courier came from, it wasn't letting go easily.

I finally had to paste into Word, strip the formatting, reset the font and text size, and then repaste into Outlook.

It's a lot easier to past into Notepad. Notepad is text only, so anything you past there automatically gets all formatting removed. So just paste in to Notepad, and then copy the stuff you pasted into Notepad, then past that into Outlook, or whatever.

You could also create a new email as text only, and past into that.

Yeah, I just happened to have Word open already so it was as easy to do it that way. But it's not a problem I've encountered before.

(As a test, I just copied your post into a blank email, and it automatically used my default font/size/color as usual.)

MS products have a sometimes annoying sometimes useful habit of transferring a lot of extra stuff (formatting and the like) via the clipboard. I use a text editor as an intermediary, if Paste Special isn't an option.

I think I have figured out why new threads start at post #2 (both here and on the PostgreSQL test site).

When a new post is added, it's written to the posts table with a value of 0 in the post_number field. Then a SELECT Count(post_number) FROM posts WHERE thread_id = current thread number is done. Then an UPDATE query is done, setting post_number = (the result of the Count) + 1.

But when the first post is added, a Count(post_number) =1, even though the post_number for that post=0. Then when the update query is run, one is added to the one, and the post_number of the first post is set to 2.

On the INSERT of the new post, can post_number be set to Null? If so, Count won't count it. (I don't remember if post_number allows Null.)

Also, if multiple posts hit the server at once, it might be possible for more than one append to happen before the update (where the post_number is set to its actual value) is run. That would explain why when the Natter thread is turned over, you might see post #s 9997, 9998, 9999, 10000, 10000, 10000, 10003, 10004.

I don't know of a simple solution to this problem for the MySQL version, but I think I know one for the PostgreSQL version. But perhaps this really isn't a significant issue...

(So far I've tried to make as few changes to the PHP code as possible.)

Didn't just happen at post equals zero, though. When we first moved over here, the first post in every thread skipped one post number. So if the last post on the old server was #699, the first post here was #701.

Edited to say that I'm not sure it was due to the same thing, but it sure looked like it.

did the sign in problems get fixed? how's testing going? what are we testing?

Once we have the code working for PostgreSQL, I think we should go on to implementing triggers for post number incrementing, et al.

But I still have to fix the filter first anyway,

The new back end.

I wonder if things were coded assuming Count(0) =0?

DX, I think my explanation still applies. I think the code will always set the post_number one too high, but after this happens once then future posts will follow in correct sequence.

msbelle, the sign-in problem was fixed (assuming there was only one sign-in problem). Last night my internet access died, so I didn't do any fixing beyond that. So there are still some known issues for me to fix.

I don't know offhand if all possible functionality has been tested yet.

edit for spelling....