and another (very strange) one:

I submitted this one also to Joomla github (see github.com/joomla/joomla-cms/issues/18204 ) so I am not describing all details here...

I did not mention the MultiSites environment in Joomla Github, but of course this could well be another possible reason for that issue. So I let you know about it here as well.

Do you have the problem described in github on the master or in a slave site ?

The issue that you describe seems to have a wrong DB connection with a wrong MySQL user / password (access denied to user).
So the question is to identify why the DB Connection would be wrong or changed during the processing as you can login in the back-end and see the articles.

I saw this issue in a number of my slave sites, and just tested it in the master site. I do get the same error also on the master.

the database user(s) indeed are correct, because the website(s) actually are working. So in some backend situations the database user seems to be altered before the sql query.

I saw you have a "multisites patch" for the database.php joomla core file, maybe something is there (sorry I am just speculating).

I will try to change the core file that causes the error (httpdocs\libraries\joomla\database\driver\mysqli.php:650 ) to see if I get any idea "which query" is the problem...

Do you have any other ideas?

kind regards
Ruediger

The patch on the DB just concern the return of a reference (&) instead of a data in a getAdapter() function.

If you want to see the patches that are installed in a source, you can search for the tag "jms2win".
All the patches are tagged.

I don't really know the reason.
I can just do hypothesis like a modification of the DB connection after that session or read of a data from another place that would change the DB connection.

Do you use extension like FALang that may overide the DB APIs ?

If you want that we debug such strange behavior, this is still possible with our billable support that you can order at
/en/joomla-multisite?page=shop.product_details&flypage=flypage_multisites.tpl&product_id=35&category_id=1

The idea would be to backup and restore your environment on a local PC to be able debugging the code when the issue occurs.
This suppose that the scenario that you have found, can also be reproduced on a local PC.
If this is not possible the only solution would be to debug on live environment that is not really recommended when website are live.

What could be done to identify the query that cause the issue is to modify the Joomla core to Try/Catch the error and collect the stack information with all the details.

Try also to enable the Joomla Debug mode to get more info on the queries.
In the footer of the pages, you will find details on the DB queries and also the stack of each call.
Perhaps that this will help you collecting the stack of the MySQL error.

thank you Edwin,
these suggestions are pretty much what I also thought would be a sensible course of action.
I will try to find out more about this (and no, I dont think it is nessessary that you start debugging our system). If I find anything that is connected to jms, I will let you know...
cheers, Ruediger

Found the issue, not connected to JMS or JOOMLA (sorry to bother you).
in the aftermath of updating to Joomla 3.8.0, we had an incident where all database users were crashed in the mysql users table. In restoring them, we missed to also grant the "LOCK TABLES" and "REFERENCES" database permissions. These seem to be relevant only in the named circumstances, and not "whenever changes are made"...