Discussion :

[msomso]

Bonjour,
J'exécute un script contenant une série d'insertions dans une même table.
Ces insertions sont de type :

Code :

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

Insert <table> (<liste colonnes>) values <(liste valeurs>)

De façon aléatoire, l'un de mes ordres d'insertion échoue sans que le moindre message ne soit généré.
Il ne s'agit pas d'erreur de type "Foreign Key":
l'insertion posant le problème est rejetée / exécutée de façon aléatoire
au fur et mesure que je repasse mon script.

Le test de la variable @@ status <> 0 est positif en cas de rejet.

Je ne trouve pourtant rien dans le log du serveur,.

Comment savoir plus sur la raison de ces échecs ?
Comment positionner une trace détaillée ?

Merci
msomso

[msomso]

Bonjour
le problème a été résolu par la suppression et recréation de la table.
Il a été spécifique à une seule de nos bases du même serveur.

Toute suggestion d'investigation de ce genre de problème, serait quand même bien venue ...

Merci
msomso

[Fabien Celaia]

Il y a pas mal de possibilités pouvant expliquer une insertion qui plante : le type de donnée, le format d'une date, la portée du domaine...

Chacune de ces erreurs génère un @@error<>0, et il faut le tester pour CHAQUE insert.

Dans le cas d'inserts massifs, si un tuple plante, c'est toute la transaction qui est rollbackée.

Les erreurs n'apparaissent pas dans le journal car elles n'ont pas une severity suffisante... Heureusement que l'errorlog ne se ramasse pas toutes les erreurs de syntaxe de n'importe quel ordre...

[msomso]

Bonjour

Heureusement que l'errorlog ne se ramasse pas toutes les erreurs de syntaxe de n'importe quel ordre...

Certes, mais dans notre cas, c'est un même (et inchangé) ordre d'insertion qui s'exécutait ou échouait de façon aléatoire.
Il ne s'agit donc absolument pas d'erreur de syntaxe.
Ce genre d'erreur est d'ailleurs clairement signalé sous isql par un message de type : "Incorrect syntax near ..."

***
Je suis d'accord qu'on doit tester @@error, mais comment poursuivre l'analyse si précisément sa valeur est <> 0 ?

Pourquoi, l'exécution directe sous isql d'un tel ordre ne génère aucun message de rejet/plantage ?

On aimerait bien avoir quelque part un indice/retour d'information du serveur ...
Merci
msomso
P.S.
Désolée pour la confusion: j'ai indiqué @@status dans mon post initial au lieu de @@error, mais j'ai bien testé la variable @@error.

[mpeppler]

Si un insert ne s'execute pas c'est qu'il y a une raison... :-)

Cela peut venir d'une stack trace ou erreur interne ASE - dans ce cas la session qui fait l'insert est en général interrompue.
Ou d'un trigger qui refuse la ligne via un "rollback trigger" - sans raiserror cela ne positionne pas le @@error.
Ou peut-être d'une autre cause qui ne me vient pas à l'esprit juste là...

Michael

[msomso]

Bonjour

Cela peut venir d'une stack trace ou erreur interne ASE

Comment statuer entre ces 2 causes plausibles ?

Nous n'avons pas défini de trigger pour la table concernée, peut être un trigger interne ... ?
Je reprécise, que dans notre cas il n'y avait aucun signe d'erreur: notamment, la session restait non interrompue.

Merci
msomso

[mpeppler]

En fait - si il y a une erreur interne il doit normallement y avoir une stack trace dans la log ASE, et une erreur de severité > 17 dans le client (ou alors interuption de la connexion).

Je ne sais pas vraiment ce qui peut ce passer dans ton cas - c'est qqch que je n'ai jamais vu.

La seule autre chose à laquelle je peux penser c'est que dans un cas tu es en autocommit on (cad chained mode off), et dans l'autre en chained mode on, et qu'il n'y a pas de commit dans le script... ou alors qu'il manque un "go" qqpart... mais c'est quand même peu probable!

Michael

[msomso]

Bonjour,
faut-il positionner explicitement un niveau pour la stack trace ?

Pour le reste : cette erreur aléatoire se produisait même en exécutant l'instruction concernée par "copier/coller" dans une session isql ouverte dans une fenêtre DOS. Dans cette même session (puisque jamais interrompue), en testant @@error et le résultat d'insertion, j'ai constaté ce qui fait l'objet de notre discussion.

Donc au départ on avait un script avec 3 inserts et 3 "GO", ensuite vu que l'un d'eux ne passait pas toujours, j'ai continué les tests sans script mais en lançant cet ordre d'insertion "à la main" par copier/coller.

Merci
msomso