Discussion :

[maitrebn]

Bonjour,

Je crée des requêtes dynamique de mise à jour de données que j'execute dans un EXECUTE.

En gros voici le principe :

-- Via un curseur
POUR CHAQUE DONNEES
-1- Creation de la requete
-2- EXECUTE(<MA_REQUETE>)


Le tout est entouré d'une transaction et après chaque execute, je teste la valeur @@ERROR et so @@ERROR <> 0 ==> Via un GOTO je vais dans la partie rollback.

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
 
-- [...]
    -- Execute
    EXECUTE(@STR_1)
    -- Erreur ?
    IF @@ERROR<>0 
	BEGIN
		GOTO ROLLBACK_TRANSACTION
	END
 
-- [...]
COMMIT_TRANSACTION:
  PRINT 'COMMIT DE LA TRANSACTION'
  COMMIT TRANSACTION
  GOTO END_TRANSACTION
ROLLBACK_TRANSACTION:
  PRINT 'ANNULATION DE LA TRANSACTION'
  ROLLBACK TRANSACTION
  GOTO END_TRANSACTION
END_TRANSACTION:
  CLOSE CUR_REQUETE
  DEALLOCATE CUR_REQUETE

Quelqu'un aurait une idée ?

[serge0934]

ton code est bon ...

par contre, pense que ta variable @@error est réinitialisée au début de TOUTE requete, donc tu dois mettre ton test après CHAQUE execute

A+

[Madinico]

Effectivement ton script SQL à l'air bon la gestion des erreurs ne me paraît pas mauvaise.

Pourrais-tu donner plus de précision sur ton problème ?

Nicolas L.

[maitrebn]

Le test est mis juste après CHAQUE execute ...

Le problème est que dans mon EXECUTE j'ai plusieurs requêtes, pour l'exemple on va dire trois :
A B C.
A & C ne pose pas de problème.
B ne respecte pas une contrainte d'intégrité ...

Si je fais : EXECUTE( A B C) dans l'analyseur de requête. Je vois que A est bien passé, que B a bien générée une erreur et que C c'est bien passée.
Mais à la fin @@ERROR contient 0 ... Je pense qu'il considère que la dernière requête c'est C qui a bien fonctionnée !

Par contre, si je fais EXECUTE( A C B), j'ai bien le message d'erreur et @@ERROR est différent de 0.

Je pense @@ERROR contient non pas la dernière instruction de ma PS mais des requêtes contenues dans EXECUTE.

Ma question est donc : comment savoir que des requêtes fait via un EXECUTE n'ont pas fonctionné.

PS : J'ai le test avec sp_executesql et j'ai le même problème !

[serge0934]

si tu est mettre de ton code dans le exécute, après chaque instruction SQL, tu mets un raiserror.ex:

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
 
-- 1° instruction
insert into ...
if @@error<>0
  raiserror('insert 1 planté',16,1)
else
  begin
    -- 2° instruction
    insert into ...
    if @@error<>0
      raiserror('insert 2 planté',16,1)
    else
      begin
        -- 3° instruction
        ....
      end
  end

comme çà, lorsque tu fait le exec le raiserror sera remonté

[maitrebn]

Effectivement j'ai pensé à cette solution ... je suis effectivement maître de mon code.

Le souci est que cela passe par un réseau WAN (< 1Mbits) et que je suis entrain de minimiser le flux ... donc je ne peux pas ajouter de nouveaux éléments dans le text que j'envoie.

PS : En fait, les requêtes sont générées par une appli, transférées sur le réseau puis exécutée par une PS ...

[maitrebn]

Pour être plus clair voici un exemple :

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

1
2
3
4
5
6
7
8
9
10
11
12
13
14
 
DECLARE @STR AS VARCHAR(8000)
 
SET @STR = ' INSERT INTO T_A(UID, UID_B, UID_C) VALUES (newid(), ''C7C86B92-EA59-4E4C-B7A5-499F69799C8C'', ''AFB38D28-7EA3-43C6-92B8-83EB9BE71505'') '
SET @STR = @STR + ' INSERT INTO T_A(UID, UID_B, UID_C) VALUES (newid(), ''C7C86B92-EA59-4E4C-B7A5-499F69799C8C'', ''E220B491-BBB2-44E4-9481-FA0157946A02'') '
SET @STR = @STR + ' INSERT INTO T_A(UID, UID_B, UID_C) VALUES (newid(), ''E220B491-BBB2-44E4-9481-FA0157946A02'', ''C7C86B92-EA59-4E4C-B7A5-499F69799C8C'') '
SET @STR = @STR + ' INSERT INTO T_A(UID, UID_B, UID_C) VALUES (newid(), ''9c96812e-6210-4a4f-af6f-7027fc0f229f'', ''AFB38D28-7EA3-43C6-92B8-83EB9BE71505'') '
SET @STR = @STR + ' INSERT INTO T_A(UID, UID_B, UID_C) VALUES (newid(), ''9c96812e-6210-4a4f-af6f-7027fc0f229f'', ''E220B491-BBB2-44E4-9481-FA0157946A02'') '
SET @STR = @STR + ' DELETE FROM T_A WHERE UID_B = ''9c96812e-6210-4a4f-af6f-7027fc0f229f'''
SET @STR = @STR + ' DELETE FROM T_B WHERE UID = ''9c96812e-6210-4a4f-af6f-7027fc0f229f'''
 
 
EXECUTE(@STR)
PRINT @@ERROR

Les deux premiers insert génèrent une erreur car ils ne respectent pas une contrainte d'unicité,
Le troisième génère également une erreur car il ne respecte pas une FK,
Les dernières requêtent sont OK.

Le résultat du print est 0.

[Madinico]

A partir du moment où tu exécute ta procédure stockée, l'ensemble de traitement est exécuté par le moteur de base de données SQL Server.
Donc tu ne passe plus par ton réseau. Tu peux donc tester tes requêtes les unes après les autres. Il n'y aura aucun transfert de flux entre la machine appelant l'exécution et le serveur SQL où s'exécute ta procédure stockée.
Il te suffit de découper la chaine passer en paramètre.

N'hésite pas à poster si tu veux plus d'explication.

Cordialement,
Nicolas L.

[hypoass]

Bjr
En fait j'ai le meme pb et j'aimerais vraiment avoir une solution. Car je n'arrive pas a recuper le code de l'erreur.Exemple
J'ai la procedure suivante:

create proc tesInsert
as
insert into cpteclthist(dateoperation) values('juin 1 2007 10:06A')
if @@error <> 0
begin
raiserror('insert 1 planté',16,1)
end

Mais lorsque j'execute cette procedure ( exec testInsert ) j'obtiend plutot :Serveur : Msg 241, Niveau 16, État 1, Procédure tes, Ligne 3
Erreur de syntaxe lors de la conversion d'une valeur datetime à partir d'une chaîne de caractères.

Je voudrais bien savoir comment intercepter ce message d'erreur. En passant je bosse avec sqlserver 2000
merci d'avance

[hypoass]

Bjr
En fait j'ai le meme pb et j'aimerais vraiment avoir une solution. Car je n'arrive pas a recuper le code de l'erreur.Exemple
J'ai la procedure suivante:

create proc tesInsert
as
insert into cpteclthist(dateoperation) values('juin 1 2007 10:06A')
if @@error <> 0
begin
raiserror('insert 1 planté',16,1)
end

Mais lorsque j'execute cette procedure ( exec testInsert ) j'obtiend plutot :Serveur : Msg 241, Niveau 16, État 1, Procédure tes, Ligne 3
Erreur de syntaxe lors de la conversion d'une valeur datetime à partir d'une chaîne de caractères.

Je voudrais bien savoir comment intercepter ce message d'erreur. En passant je bosse avec sqlserver 2000
merci d'avance

[maitrebn]

A partir du moment où tu exécute ta procédure stockée, l'ensemble de traitement est exécuté par le moteur de base de données SQL Server.
Donc tu ne passe plus par ton réseau. Tu peux donc tester tes requêtes les unes après les autres. Il n'y aura aucun transfert de flux entre la machine appelant l'exécution et le serveur SQL où s'exécute ta procédure stockée.

Je suis désolé mais j'ai pas du être clair ...

En fait, mon prog envoie directement (via la reseau ) dans une même chaine plusieurs requêtes.

Un exemple : J'ai 10 000 Insert à faire. Je le regroupe par 100 dans des chaînes de charactères que j'enregistre dans un table temporaire. Une fois les 100 paquets enregistrés, j'appele une PS qui va boucler sur les différents parquets et pour chaque directement appeler EXECUTE.

Donc pour ajouter le texte de contrôle, il faut que le fasse au moment de la création des paquets ce qui va augmenter mon flux ...

Mais j'ai l'impression que mon problème est insoluble ...

[maitrebn]

Bjr
insert into cpteclthist(dateoperation) values('juin 1 2007 10:06A')

T'as essayé de changer la forme de ta date ? '01/06/2007 10:06'.

[phoenix38]

Bonjour,
Une solution serait peut-être de passer par une table "JOURNAL" dans laquelle tu enregistrerait les messages d'erreur en temps réel à la place d'un raiserror...

Pour les dates essaies de les mettre au format yyyy-mm-ddThh:mm:ss (le T n'est pas une faute de frappe). Avec ce format, tu n'as plus de pb de localisation...

[maitrebn]

Je ne comprends pas trop le principe dans la table JOURNAL ... Car ca la va également ma générer du flux supplémentaire ?

[phoenix38]

Je ne pense pas.
Le pb de @@ERROR c'est qu'il n'est pas persistant, il faut "l'utiliser" tout de suite.
Tu crée une table JOURNAL (ou autre) dans laquelle tu vas stocker le message au moment même où il arrive.
A la fin de ton block tu fais un select sur cette table.
Le traffic sera proportionnel aux erreurs que tu auras eu (pas plus je pense que plusieurs raiserror)

[maitrebn]

Ok je vois mieux !

En fait, comme j'enregistre les flux, il faudrait que dans mon flux je mette également l'enregistrement dans la table journal ... donc mon flux augmenterait ...

[maitrebn]

Je crois que c'est bon j'ai trouvé !

Il faut mettre la commence XACT_ABORT a ON. D'apres la doc, cela coupe toute transaction en cours dès la première erreur !

J'ai fait plusieurs tests et il semble que cela resolve mon problème.