sp_executesql n'exécute pas le code..

Bonjour,
j'ai la proc stock suivante qui au lieu de faire l'update, me fait un select de @SQLString et retourne 0. Vous savez pourquoi? sp_executesql est bien sensé exécuter le contenu de la chaîne de caractères, non?
Le contenu qui m'est retourné de SQLString est :

Citation:

---

update RequestPayment set Status = @Status from RequestPayment rp where rp.RequestPaymentOID in (5,6)

---

J'appelle la proc stock de cette manière:

Code:

---

1 2 3

declare @ret int exec @ret = upd_csa_RequestPayment '5,6', 'V' select @ret

---

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 35 36 37 38 39 40 41 42 43 44 45 46 47 48 49 50

CREATE PROCEDURE [dbo].[upd_csa_RequestPayment] -- Add the parameters for the stored procedure here ( @OIDList nvarchar(3500), @Status nchar(1) ) AS BEGIN DECLARE @error INT, @SQLString nvarchar(4000), @CharVariable nchar(1), @ParmDefinition nvarchar(50) SET @error = 0 select @CharVariable = @Status select @ParmDefinition = N'@Status nchar(1)'   select SQLString = N'update RequestPayment set Status = @Status from RequestPayment rp where rp.RequestPaymentOID in (' + @OIDList + N')'   /*if ()   GOTO NOK1*/   begin transaction update_RequestPayment   EXECUTE sp_executesql @SQLString, @ParmDefinition, @Status = @CharVariable   set @error = @@ERROR if @error = 0 begin GOTO OK end else begin GOTO NOK2 end     OK: commit transaction update_RequestPayment return 0   /*NOK1: return -1*/   NOK2: rollback transaction update_RequestPayment return -2     END

---

1) Faites une exécution avec EXEC (@Machaine) au lieu de sp_executeSQL, et voyez avec un print ce que contient la variable.
2) l'utilisation des GOTO est à proscrire. Utilisez des blocs TRY / CATCH.
3) nommer des transaction ne sert pas à grand chose

A +

Exec(machaine) c'est ce que j'ai fait au début mais il s'attend à executer une procedure stockée. Sinon pour le contenu de la chaîne à executer, il est indiqué en citation dans mon 1er message.

Voila comment écrire votre proc

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

CREATE PROCEDURE [dbo].[upd_csa_RequestPayment] @OIDList nvarchar(3500), @STATUS nchar(1), @RETVAL INT OUTPUT AS BEGIN   BEGIN TRY   DECLARE @SQLString nvarchar(max);   SET SQLString = N'update RequestPayment set Status = ''' + @Status + '''from RequestPayment rp where rp.RequestPaymentOID in (' + @OIDList + N');'   EXEC (@SQLString);   SET @RETVAL = 0;   END TRY BEGIN CATCH   SET @RETVAL = -2;   END CATCH   END

---

Nombreuses erreurs :
1) ne pas utiliser RETURN n. En effet, retourner une valeur écrase la pile des erreurs. En fait la valeur retourner par RETURN est le code d'erreur. Utilisez une variable en OUTPUT pour ce faire, si vous désirez renvoyer une information personnalisée d'ereur, ou alors lancez une instruction RAISERROR.
2) tout ordre de mise à jour est une transaction. Il est donc parfaitement inutile de rajouter une transaction explicite.
3) les transactions nommées ne servent à rien en pratique
4) utilisez de préférence EXEC (@Mavariablechaine) à sp_executeSQL lorsque l'ordre SQL est peu complexe.
5) pour gérer des erreurs, utilisez les bloc TRY CATCH au lieu de la programmation spaghetti à l'aide de GOTO ! (dixit l'aide en ligne : Utilisez l'instruction GOTO avec parcimonie)

Bref, formez vous à Transact SQL !

A +

Bonjour,

Votre erreur vient de là :

Code:

---

1 2 3 4 5

SELECT SQLString = N'update RequestPayment set Status = @Status from RequestPayment rp where rp.RequestPaymentOID in (' + @OIDList + N')'

---

vous n'affectez pas la chaine à votre variable, mais vous faite une requête dont le résultat contient une seule colonne qui s’appelle SQLString, c'est la requete que vous voyez, et du coup votre EXEC éxecute une chaine vide.

Ajoutez l'@ :

Code:

---

1 2 3 4 5

SELECT @SQLString = N'update RequestPayment set Status = @Status from RequestPayment rp where rp.RequestPaymentOID in (' + @OIDList + N')'

---

merci aieeeuuuuu pour votre aide, c'était effectivement juste un problème lié à l'oubli du @...
Attention SQLPro, la correction que vous m'avez donnée ne fonctionne pas du coup mais merci quand même d'avoir pris quelques instants pour tenter de résoudre le problème.