[SQL2K] Récupération Erreur lors d'un execute

Version imprimable

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:

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 ?

31/05/2007, 09h14
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+
31/05/2007, 09h56
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.
31/05/2007, 19h21
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 !

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

Code:

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é

01/06/2007, 09h51
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 ...

Pour être plus clair voici un exemple :

Code:

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.

01/06/2007, 11h33
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.
01/06/2007, 12h02
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
01/06/2007, 12h03
hypoass

Recuperartion d'une erreur lors d'un execute

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
01/06/2007, 13h11
maitrebn

Citation:

Envoyé par 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.

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 ...
01/06/2007, 13h18
maitrebn

Citation:

Envoyé par hypoass

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'.
01/06/2007, 15h17
phoenix38

Re

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...
01/06/2007, 15h25
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 ?
01/06/2007, 15h34
phoenix38

Re

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)
01/06/2007, 17h45
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 ...
01/06/2007, 17h46
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.