Discussion :

[sevyc64]

Bonjour à tous,

Sur SQL Server 2017, je n'arrive pas à comprendre comment une requête est exécutée et surtout comment elle arrive à me faire une erreur.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

SELECT MAX(CONVERT(INTEGER, z.NoChrono)) FROM (select * from MaTable INNER JOIN @Temp ON IDtemp = IDMaTable) z;

NoChrono est une colonne de MaTable, de type varchar(50) qui peut parfois contenir des valeurs alphanumériques, mais qui contient uniquement du numérique la plupart du temps.
@Temp est une table temporaire qui est remplie suite à divers traitements, par certains ids de la table MaTable.

La jointure des 2 tables ne doit retourner que des lignes de MaTable ou la colonne NoChrono ne peut contenir qu'un nombre, et c'est bien le cas qu'en je l'exécute seule, je l'ai vérifié.
Cependant, quand j'exécute la requête complète, je me ramasse un message d'erreur

Échec de la conversion de la valeur varchar 'AN0001' en type de données int

comme si le convert se faisait sur la totalité de la table physique au lieu de n'être fait que sur le résultat de la jointure. AN0001 est bien une donnée "normale" de cette colonne mais qui est filtrée justement par la jointure pour ne pas être prise en compte.

Je précise que ce code fonctionne sans problème dans les même conditions depuis bientôt 10 ans. Il pête tout d'un coup, là maintenant, sur la base client sans que j'arrive à comprendre pourquoi.

[SQLpro]

C'est simple et classique... La volumétrie fait changer de plans, de stratégie, etc... pour une meilleure optimisation ! Si tu as du bottom UP le cas est classique. La conversion peut alors être effectué avant la jointure. C'est pour cela que les fonction TRY_CAST, TRY_CONVERT et TRY_PARSE ont été ajoutée !

A +

[sevyc64]

Je ne pense pas que ce soit du à la volumétrie, ça se produit sur de très petites bases, et jusque là ça ne se produisait pas même sur de très grosses bases (tout est relatif, on parle d'une 100ène de Go, 2 pour la plus grosse).

Mais effectivement, j'ai appris fortuitement que lors d'une maj récente du logiciel aurait été diffusé, à l'ensemble des clients donc, des modifications sur la base pour "optimiser les plans d’exécutions" afin améliorer les performances de certains process chez certains, une petite poignée, de nos gros clients. Je ne sais pas en quoi consiste ces modifications, je ne sais rien voir de pertinent en faisant un DatabaseCompare.

Je vais donc refiler la patate chaude au service concerné afin qu'ils me fournissent une requête corrigée et adaptée au nouveau fonctionnement ! Après tout, c'est eux qui sont reconnus expert SQL, c'est donc leur job !