Bienvenue à Blogs CodeS-SourceS Identification | Inscription | Aide

SQL Server : Affectation de variable par SELECT ou SET ?

La où la plupart du temps dans un langage de développement soit il ne faut pas de commande pour affecter une valeur à une variable, un simple opérateur = suffit ou seul une commande fait l'affaire dans d'autres, dans SQL Server il en va autrement.

En effet il est possible d'affecter une valeur à une valeur de 3 manières différentes.

-- SET
DECLARE
@i int ;
SET
@i = 1 ;

-- SELECT
DECLARE
@i int ;
SELECT
@i = 1 ;

-- 2008 uniquement
DECLARE
@i int = 1 ;

En dehors de l'aspect esthétique, qui aura plus où moins d'adeptes de l'une ou l'autre des méthodes, il faut savoir que le SET et le SELECT ont chacun leur spécificité.

Le SET ne supporte que les valeurs scalaires en cas d'affectation depuis une requête (à noter que les parenthèses sont obligatoires):

DECLARE @i int ;
SET
@i = (SELECT object_id FROM sys.objects WHERE name = 'sysrowsets')

-- Invalide
SET
@i = (SELECT object_id FROM sys.objects)

-- Invalide
SET
@i = (SELECT object_id, name FROM sys.objects WHERE name = 'sysrowsets')

Vous aurez comme message d'erreur :

Msg 512, Level 16, State 1, Line 2

Subquery returned more than 1 value. This is not permitted when the subquery follows =, !=, <, <= , >, >= or when the subquery is used as an expression.

A l'opposé le SELECT supporte les affectations multiples, et sans problèmes le fait d'avoir plusieurs lignes retournées

DECLARE @i int ;
DECLARE
@name sysname ;

SELECT @i = object_id, @name = name FROM sys.objects

Le problème étant ici de savoir quelle valeur et contenue dans les variables @i et @name ? C'est la « dernière » valeur, en fait celle des colonnes de la dernière ligne traitée, mais cela n'empêche pas le moteur d'exécuter en totalité cette requête !

Moralité le SET sert quand on souhaite récupérer une valeur et une seule, on peut se servir de l'erreur renvoyé par ce dernier si plusieurs lignes sont retourné par le SELECT dans un TRY / CATCH par exemple, cela garantie que la sous requête s'exécute sans problèmes.

Le SELECT quant à lui, servira dès lors que j'ai besoin d'affecter plusieurs variables simultanément :

DECLARE @count int, @error int ;

SELECT 1 / 0

SELECT @count = @@ROWCOUNT, @error = @@ERROR ;

Ou que le jeu de résultat du SELECT est susceptible de me renvoyer plusieurs lignes et à condition que ce soit logique de ne récupérer que la dernière ligne et d'ignorer toutes les autres. Faites bien attention à ce comportement j'ai vu beaucoup d'erreur de logique à cause de cela… En cas de doute l'ajout d'un TOP(1) dans le SELECT peut aider à la lisibilité de code.

Bonne affectation...

Ce post vous a plu ? Ajoutez le dans vos favoris pour ne pas perdre de temps à le retrouver le jour où vous en aurez besoin :
Publié jeudi 10 décembre 2009 09:02 par christian
Classé sous : ,

Commentaires

Pas de commentaires
Les commentaires anonymes sont désactivés

Les 10 derniers blogs postés

- TFS 2013 : Migration d’une ferme TFS 2010 vers 2013 sans upgrade par Blog Technique de Romelard Fabrice le 05-01-2015, 16:28

- [ #SharePoint 2016 ] frappe à nos portes ! (1/2) par Le blog de Patrick [MVP Office 365] le 04-19-2015, 23:21

- Lync devient Skype Entreprise par Le petit blog de Pierre / Pierre's little blog le 04-18-2015, 22:47

- [WCF] Prendre la main sur les protocoles par Blog de Jérémy Jeanson le 04-18-2015, 12:57

- yOS Tour Geneva - Retour des sessions par Blog Technique de Romelard Fabrice le 04-16-2015, 11:54

- YOS Genève 2015 : gestion des gros fichiers et plus … par The Mit's Blog le 04-13-2015, 11:56

- YOS Genève 2015 : App et bonnes pratiques par The Mit's Blog le 04-13-2015, 10:55

- [YOS Genève 2015] : Et si on adoptait enfin nos espaces collaboratifs par The Mit's Blog le 04-13-2015, 09:48

- [WCF] Les bases d’une configuration clean par Blog de Jérémy Jeanson le 04-11-2015, 11:48

- Dernière partie de cache cache avec l’AppFabric le 2/04/2016 par Blog de Jérémy Jeanson le 04-08-2015, 23:01