Depuis la version 2008 de SQL Server 2008, il est possible de passer comme argument à une fonction ou une procédure, une table définie par l'utilisateur.
Cela est une réponse à l'attente de nombreux développeurs.
Pour ceux qui, comme moi, n'ont pas une version 2008 voici ma solution alternative au problème en ce qui concerne les procédures.
Qautres choses importantes seront à noter.
1. Nous ne définirons pas de procédure, lancer le traitement que nous allons définir se fera par des opérations d'insertion (si, si !).
2. Nous n'aurons pas la possibilité d'employer autre chose qu'une table unique pour renseigner des données à notre traitement.
Vous n'aurez donc pas une table et plusieurs paramètres, vous aurez une table, point final.
3. Le traitement ne pourra pas servir à renvoyer des données.
4. Des traitements différents sur des tables de même structures nécessiteront chacun la définition d'une view propre, même s'il ces view sont parfaitement identique (à l'exception du nom, bien sûr) dans leur définition.
Comment faire ?
Vous devez tous d'abors définir une view qui reprendra la structure de la table utilisée pour le traitement.
Pour la définition de cette view, je vous recommande de définir des colonnes renvoyant des valeurs NULL castées dans le type de la colonne car mettre une valeur non NULL n'aurait pas beaucoup de sens et pourrait semer la confusion de la personne qui relira votre code.
Ma table n'a ici qu'un seul paramètre, Id qui est du type BIGINT.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 CREATE VIEW vWORK_test AS SELECT CAST(NULL AS BIGINT) AS Id
Si nous essayons maintenant une insertion sur cette table, nous aurons droit à une belle erreur qui ne devra pourtant pas nous effrayer.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 INSERT vWORK_test(id) SELECT 5 UNION SELECT 10Mais... Même pas peur !Msg 4406, Level 16, State 1, Line 1
Update or insert of view or function 'vWORK_test' failed because it contains a derived or constant field.
Cette erreur est la conclusion logique d'une tentative d'insertion dans une colonne constante sur une view. Cette erreur ne sera plus dans la suite de la solution.
Nous allons maintenant définir notre traitement dans un trigger qui sera appellé à la place du comportement d'insertion par défaut (qui nous a vallu ce beau message d'erreur).
Dans notre trigger, nous avons donc à disposition du traitement cet accès que nous désirions à une table en tant que "paramètre", cette table est inserted.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24 CREATE TRIGGER vWORK_test_IOINSERT ON vWORK_test INSTEAD OF INSERT AS BEGIN SET NOCOUNT ON DECLARE @tTralala TABLE ( X BIGINT , miX FLOAT ) INSERT @tTralala ( X , miX ) SELECT Id , Id / 2.0 FROM inserted END
Ce trigger ci n'a par ailleurs aucunne utilisé sinon à servir d'exemple.
Vous pouvez testez.
Et cette fois tout se passera bien.
Code : Sélectionner tout - Visualiser dans une fenêtre à part
1
2
3
4
5 INSERT vWORK_test(id) SELECT 5 UNION SELECT 10
Bon amusement.
Serge.
Partager