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

- Créer un périphérique Windows To Go 10 ! par Blog de Jérémy Jeanson le 11-21-2014, 04:54

- RDV à Genève le 12 décembre pour l’évènement “SharePoint–Office 365 : des pratiques pour une meilleure productivité !” par Le blog de Patrick [MVP Office 365] le 11-19-2014, 10:40

- [IIS] Erreurs web personnalisées par Blog de Jérémy Jeanson le 11-19-2014, 00:00

- BDD/TDD + Javascript par Fathi Bellahcene le 11-16-2014, 16:57

- Sécuriser sans stocker de mots de passe par Blog de Jérémy Jeanson le 11-15-2014, 08:58

- Où télécharger la preview de Visual Studio 2015 ? par Blog de Jérémy Jeanson le 11-13-2014, 21:33

- Les cartes sont partout ! par Le blog de Patrick [MVP Office 365] le 11-13-2014, 17:26

- [ #Office365 ] Courrier basse priorité ! par Le blog de Patrick [MVP Office 365] le 11-12-2014, 08:56

- [Oracle] Fichier oranfsodm12.dll absent du package client par Blog de Jérémy Jeanson le 11-10-2014, 20:44

- [ #Office365 ] Le chapitre 1 des Groupes est écrit, et alors ? par Le blog de Patrick [MVP Office 365] le 11-10-2014, 20:23