does the user have more than one membership on the forum in question?  Or are they in a single usergroup with access to the forum?

Since the ‘best’ membership wins with multiple memberships, its possible there is an unintended consequence in this case, ie edit forever not checked first…

we havent adjust anything in this area in quite some time…

Since you are not using the api for adding membership and doing it directly in mysql, you might have a caching issue.  We cache all of a users memberships and use them rather than loading them all the time…  with your method of adding, we wouldnt know to reset the user’s cache… 

please try going to forum – toolbox – housekeeping and resetting the auths cache and see if that clears it up….  If it does, you will have to do that housekeeping each time you change a membership directly in mysql.

Thanks Steve.

It’s working now, I think the auth cache reset did the job, glad to read auth data are cached btw 

Your explanations make me think about some questions about the multiple membership and possible issues, but I need to get a better understanding on how it works and maybe experiment with it before coming with questions…

I hope my problem that force me to manually add the members to a user group will get a fix soon, I’m convinced the issue is not related to my system or database setup.

Cheers. 

thanks for the update…

as to the membership stuff, the only issue we can replicate is potentially running out of memory or cpu time… so we are changing the queries involved and trying to see if we can do it in chunks… our testing is normally with 250k users, but our test servers may not be representative of everyone’s servers..

Resources wise, my server is quite powerfull, it’s a Xeon E5-1650 processor with 6 cores/12 threads and 64 GB of RAM and it’s dedicated to WordPress blog and SP forum.

Still, I agree with Andy’s comments about the membership query creating a temporary table, that shouldn’t be. I’ll try to have a look in that direction.

Thanks for your support.

understand… work in progress… its still going to require a temp table, just not in RAM, I believe…