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

- SharePoint 2013: Préparation de la migration - Création des site Templates dans 2010 et 2013 par Blog Technique de Romelard Fabrice le 08-20-2014, 16:31

- [ #Yammer ] How to change interface language ? Comment changer la langue de l’interface ? par Le blog de Patrick [MVP SharePoint] le 08-20-2014, 14:21

- Onedrive Sync Engine Host : CPU à 100% par Le petit blog de Pierre / Pierre's little blog le 08-06-2014, 22:22

- SharePoint : Bug sur la gestion des permissions et la synchronisation Office par Blog Technique de Romelard Fabrice le 07-10-2014, 11:35

- SharePoint 2007 : La gestion des permissions pour les Workflows par Blog Technique de Romelard Fabrice le 07-08-2014, 11:27

- TypeMock: mock everything! par Fathi Bellahcene le 07-07-2014, 17:06

- Coding is like Read par Aurélien GALTIER le 07-01-2014, 15:30

- Mes vidéos autour des nouveautés VS 2013 par Fathi Bellahcene le 06-30-2014, 20:52

- Recherche un passionné .NET par Tkfé le 06-16-2014, 12:22

- [CodePlex] Projet KISS Workflow Foundation lancé par Blog de Jérémy Jeanson le 06-08-2014, 22:25