Je cherche confirmation de l'impossibilité d'effectuer directement la mise à jour suivante: dasn une table j'ai un champ priorité, je souhaite mettre certaines de ces priorités au niveau max déjà existant
 
J'ai donc essayé ceci:

 
Le problème est, il me semble, que ACCESS n'accepte pas bien les update/delete mixés avec des regroupements ou calculs.
 
Le seul moyen que je trouve c'est macro avec création d'une table bidon où je stocke le max et ensuite la MAJ.
 
Est-ce que j'ai manqué une astuce?
 
Merci pour vos confirmations, ou mieux, astuces  

Je dirais surtout que tu as un problème de parenthères...

Ah non, excuse-moi, pas fait gaffe, c'est bon en fait.
 
Vire les parenthèses dans ton where, elles servent à rien et c'est illisible.

Bon, je reposte ce que j'avais posté en premier :
 
En fait, SQL Server (et Oracle aussi il me semble) supportent pas la mise à jour d'un champ dans une requête s'il est replacé par une valeur du même champ, soumise à une condition qui pourrait ne plus être vérifiée suite aux modification.
 
Imagine :
 
Table de 200 Mo
Mémoire de 16 Mo
Swap de 64 Mo
(c'est la config d'un certain nombre de machine "serveur" encore à l'heure actuelle)
 
Bon, ben on voit bien que le SGBD aurait beau faire tout ce qu'il voudra, il devrait la faire en plusieurs fois cette requête.
 
Hors, s'il commence à faire la requête et que les nouvelles valeurs rendent la condition, ou la valeur de remplacement différente pour les données qui seront mises à jours dans la passe suivante, alors on casse toute l'intégrité de la base.
 
Donc ça bloque.
 
Ta requête en elle-même ne fait pas ça, mais imagine que tu fasses un max() + 1, à ce moment tu comprendras vite ce que je veux dire : le deuxième lot de mises à jour va se baser sur les données qui viennent juste d'être inserrée, et c'est donc max() +  qui sera réellement insérré, et ainsi de suite.
 
Du coup Access te pète à la figure à cause de ça. SQL Server fait pareil. J'ai pas de base Oracle pour confirmer qu'il bloque aussi (d'un autre côté Oracle effectue ses transactions internes d'une façon un peu plus poussée que SQL Server donc il n'a peut-être pas cette limitation)

Merci pour la réponse.
 
Je n'avais pas trop poussé la réfléxion et ce que tu exposes est plein de bon sens et apparaît assez évident après coup .
 
Pour les parenthèses c'est juste que pour simlfier et recentrer sur mon problème j'ai allégé la requête un tant soit peu
 
Aller, c'est parti pour une table bidon!