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)
.
