[2008R2] SP et paramètre output

SP et paramètre output

Bonjour,

J'ai un souci avec une procédure stockée dont un paramètre output reste NULL sans que je comprenne pourquoi. C'est bien sûr assez ennuyeux ^^.

Sans plus attendre, voici le code de la SP en quesiton :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
CREATE PROCEDURE [dbo].[UP_AREA_SAVE]
    @ARE_ID INT,
    @ARE_NAME VARCHAR(5),
    @ARE_X    DECIMAL(5,2),
    @ARE_Y    DECIMAL(5,2),
    @FLO_ID    TINYINT,
    @NEW_ID INT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
 
    IF @ARE_ID = 0
    BEGIN
        INSERT INTO dbo.T_AREA_ARE(ARE_NAME, ARE_X, ARE_Y, FLO_ID)
        VALUES(@ARE_NAME, @ARE_X, @ARE_Y, @FLO_ID);
 
        SET @NEW_ID = SCOPE_IDENTITY();
    END
    ELSE
        UPDATE    dbo.T_AREA_ARE
        SET        ARE_NAME = @ARE_NAME,
                ARE_X = @ARE_X,
                ARE_Y = @ARE_Y
        WHERE
                ARE_ID = @ARE_ID
END

Il s'agit donc une SP chargée de sauver en DB un objet que lui envoyé un application .NET. Si @ARE_ID = 0, il s'agit d'un nouvel objet --> insertion d'une ligne, sinon il s'agit d'un objet existant --> édition d'une ligne.

Voici la définition de la table T_AREA_ARE :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
CREATE TABLE [dbo].[T_AREA_ARE](
    [ARE_ID] [int] IDENTITY(1,1) NOT NULL,
    [ARE_NAME] [varchar](5) NOT NULL,
    [ARE_X] [decimal](5, 2) NOT NULL,
    [ARE_Y] [decimal](5, 2) NOT NULL,
    [FLO_ID] [tinyint] NOT NULL,
    [ARE_CREATED_ON] [datetime] NOT NULL,
    [ARE_CREATED_BY] [varchar](100) NOT NULL,
    [ARE_MODIFIED_ON] [datetime] NULL,
    [ARE_MODIFIED_BY] [varchar](100) NULL,
 CONSTRAINT [PK_T_AREA_ARE] PRIMARY KEY CLUSTERED 
(
    [ARE_ID] ASC
)WITH (PAD_INDEX  = OFF, STATISTICS_NORECOMPUTE  = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS  = ON, ALLOW_PAGE_LOCKS  = ON) ON [PRIMARY]
) ON [PRIMARY]
 
GO
 
SET ANSI_PADDING OFF
GO
 
ALTER TABLE [dbo].[T_AREA_ARE]  WITH CHECK ADD  CONSTRAINT [FK_T_AREA_ARE_T_FLOOR_FLO] FOREIGN KEY([FLO_ID])
REFERENCES [dbo].[T_FLOOR_FLO] ([FLO_ID])
ON UPDATE CASCADE
GO
 
ALTER TABLE [dbo].[T_AREA_ARE] CHECK CONSTRAINT [FK_T_AREA_ARE_T_FLOOR_FLO]
GO
 
ALTER TABLE [dbo].[T_AREA_ARE] ADD  DEFAULT (getdate()) FOR [ARE_CREATED_ON]
GO
 
ALTER TABLE [dbo].[T_AREA_ARE] ADD  DEFAULT (suser_sname()) FOR [ARE_CREATED_BY]
GO

J'ai donc bien une colonne IDENTITY et donc la fonction SCOPE_IDENTITY utilisée après l'ordre d'insertion devrait me retourner l'id nouvellement inséré. Or ce n'est pas le cas et je ne vois pas du tout d'erreur.

Je fais identiquement la même chose (aux noms des tables, colonnes et variables près) avec une autre table et là, tout se passe bien. Voici le code d'une SP qui ne pose pas de problème :

Code:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
CREATE PROCEDURE [dbo].[UP_BRAND_SAVE]
    @BRA_ID INT,
    @BRA_NAME VARCHAR(50),
    @BRA_CODE INT,
    @NEW_ID INT OUTPUT
AS
BEGIN
    SET NOCOUNT ON;
    IF @BRA_ID = 0
    BEGIN
        INSERT INTO dbo.T_BRAND_BRA(BRA_CODE, BRA_NAME)
        VALUES(@BRA_CODE, @BRA_NAME);
 
        SET @NEW_ID = SCOPE_IDENTITY();
    END    
    ELSE 
        UPDATE    dbo.T_BRAND_BRA
        SET        BRA_NAME = @BRA_NAME,
                BRA_CODE = @BRA_CODE
        WHERE
                BRA_ID = @BRA_ID
END

Mis à part les noms des tables, variables et colonnes, je ne vois strictement aucune différence.

C'est grave docteur ?

Est-ce que tu as un trigger qui se déclenche lors d'un INSERT sur la table ?

A noter aussi qu'il y a un bug connu avec SCOPE_IDENTITY, voir ici.

Bingo !

Le trigger. Je savais bien que ça allait être un truc gros comme un éléphant dans un couloir et que je ne le voyais pas....

Bon bin je corrige en remplaçant SCOPE_IDENTITY() par une requête sur la clef alternative de la table ^^.

C'est un peu plus long mais ça marche aussi.

Merci (une fois de plus) DotNetMatt !