Bonsoir,
Dans le cadre d'un projet de migration vers sql server, je dois convertir un
grand nombre de requêtes en procédure stockée.
Ca pour le moins c'est normal...
Mais comme j'ai des problèmes de performances, je voudrais être sur que la
procédure stockée ci-après ne pourrait pas être améliorée.
====================================================
create PROCEDURE [dbo].[MAJ_client] @this_cli float, @this_caanu float
AS
if exists (SELECT ref_client_fam FROM tb_client WHERE ref_client =
@this_cli )
UPDATE tb_client SET CAANU = @this_caanu WHERE ref_client = @this_cli
else
INSERT INTO tb_client (ref_client, CAANU ) VALUES ( @this_cli ,
@this_caanu )
=======================================================
Il s'agit d'une simple mise à jour qui devient un ajout si l'enregistrement
n'existe pas.
Il me semble que dans cette procédure on fait deux recherches (les deux
WHERE).
N'y aurait il pas moyen de faire directement un UPDATE et si cela ne va pas
l'INSERT
Quelqu'un a t'il de l'expérience en ce domaine ?
Merci d'avance
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
GOLD
Comme je viens d'avoir la réponse, je la mets à la disposition de ce forum, on ne sait jamais...
=============================================================== Bien évidemment la réponse est apparue en sql server version . 2008 ! (http://msdn.microsoft.com/en-us/library/bb510625.aspx)
Dans les versions antérieures il est important de garder à l'esprit qu'il faut programmer « en forçant le passage » (donc de ne pas chercher à faire de contrôle en amont de l'action).
Dans le cas actuel on peut utiliser au choix @@error ou @@rowcount :
@@error : s'il existe une contrainte (PK ?) la tentative d'insertion générera une erreur qu'il suffit de gérer par une structure try . catch ou par un if immédiatement après l'instruction.
@@rowcount : donne le nombre de lignes qui viennent d'être traitées.
En imaginant que la clause update qui vient d'être jouée a modifié 0 ligne alors il est envisageable de procéder à un insert
Dans tous les cas, 1) on tente . 2) on avise
Comme je viens d'avoir la réponse, je la mets à la disposition de ce forum,
on ne sait jamais...
===============================================================
Bien évidemment la réponse est apparue en sql server version . 2008 !
(http://msdn.microsoft.com/en-us/library/bb510625.aspx)
Dans les versions antérieures il est important de garder à l'esprit qu'il
faut programmer « en forçant le passage » (donc de ne pas chercher à faire
de contrôle en amont de l'action).
Dans le cas actuel on peut utiliser au choix @@error ou @@rowcount :
@@error : s'il existe une contrainte (PK ?) la tentative d'insertion
générera une erreur qu'il suffit de gérer par une structure try . catch ou
par un if immédiatement après l'instruction.
@@rowcount : donne le nombre de lignes qui viennent d'être traitées.
En imaginant que la clause update qui vient d'être jouée a modifié 0 ligne
alors il est envisageable de procéder à un insert
Comme je viens d'avoir la réponse, je la mets à la disposition de ce forum, on ne sait jamais...
=============================================================== Bien évidemment la réponse est apparue en sql server version . 2008 ! (http://msdn.microsoft.com/en-us/library/bb510625.aspx)
Dans les versions antérieures il est important de garder à l'esprit qu'il faut programmer « en forçant le passage » (donc de ne pas chercher à faire de contrôle en amont de l'action).
Dans le cas actuel on peut utiliser au choix @@error ou @@rowcount :
@@error : s'il existe une contrainte (PK ?) la tentative d'insertion générera une erreur qu'il suffit de gérer par une structure try . catch ou par un if immédiatement après l'instruction.
@@rowcount : donne le nombre de lignes qui viennent d'être traitées.
En imaginant que la clause update qui vient d'être jouée a modifié 0 ligne alors il est envisageable de procéder à un insert
