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 :
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.
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
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
Voici la définition de la table T_AREA_ARE :
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.
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
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
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 :
Mis à part les noms des tables, variables et colonnes, je ne vois strictement aucune différence.
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 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
C'est grave docteur ?
Partager