Discussion :

[Batou69]

Bonjour,

Nous avons actuellement un serveur de production sous SQL Server 2012 SP2 (11.0.5058) sur un serveur 2012.
Ce serveur héberge la base de données de production qui est au niveau de compatibilité 110 (la plus haute)

Pour accéder aux données, nous utilisons exclusivement des procédures stockées ne contenant qu'un seul statement (insert, update, delete ou select). Chaque procédure peut néanmoins contenir de nombreux CTE.

L'application fonctionne correctement mais j'ai remarqué dans le profiler que le serveur lance une exception Error 156 Sev 15 à chaque fois qu'une procédure d'insert ou d'update est exécutée....
L'exception est :
"Syntaxe incorrecte vers le mot clef 'XXXX'"

Où XXXX est UPDATE ou INSERT (je n'ai pas capturé de DELETE dans la trace)

Or la commande est belle et bien exécutée correctement.....
Ci joint la trace obtenue


Et la requete qui est surlignée :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
CREATE PROCEDURE [dbo].[Arche_UpdateEmplacement_100]
					@NO_EMPLACEMENT	INT	
AS
	UPDATE
		[TraceTri].[EMPLACEMENT]
	SET
		DATE_AFFECTATION = GETDATE()
	WHERE
		NO_EMPLACEMENT = @NO_EMPLACEMENT
 
GO

Merci pour votre aide

[elsuket]

Bonjour,

Il vous faut rajouter l'événement Exception de la catégorie Errors and Warnings

@++

[Batou69]

Bonjour,

Il vous faut rajouter l'événement Exception de la catégorie Errors and Warnings

@++

Merci pour votre réponse,

mais je ne la comprend pas ou bien je ne sais pas de quoi vous parlez. Il me semble que c'est justement cette catégorie que j'ai affiché dans ma copie d'écran. elle est donc bien dans la trace. A moins que vous ne fassiez allusion à autre chose que je ne connais pas.

[Boubou2020]

ouvrir Profiler.
Sur la Outils menu, cliquez sur sélection des événements puis cocher l'option Afficher tous les événements
cliquer Sur onglet Eventslog, cocher l'option "Error and Warning"

[Batou69]

Alors nous parlons bien de la même chose.

Et c'est bien ce que j'ai fait puisque sur la copie d'écran que j'ai mise, on voit bien les exceptions
(sous entendu que si on les ajoute pas, on ne les voit pas ! )

[Batou69]

Alors comme cela n'a pas l'air d'être clair dans mon premier message, je précise ce qui se passe :

J'utilise le profiler pour traquer les exceptions (en ajoutant bien cette classe d'évènements hein ) et je vois que j'en ait beaucoup. Or l'application qui execute les procédures et qui accède à la base ne voit pas d'exception, la requête est correctement exécutée, et compte tenu de sa simplicité, je ne vois pas ce qui pourrai provoquer cela.....

Des idées ?

[Boubou2020]

est ce que je peut avoir la totalité du message qui s’apparaît dans le textdata "Syntaxe incorrecte vers le mot clef 'XXXX'"

[Batou69]

est ce que je peut avoir la totalité du message qui s’apparaît dans le textdata "Syntaxe incorrecte vers le mot clef 'XXXX'"

He bien il n'y a rien d'autre.... juste ce que l'on voit dans la trace.

J'ai oublié de préciser que le SQL est en version standard

et pour être vraiment complet, voici le definition de la table

Code :

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

1
2
3
4
5
6
7
8
9
10
11
CREATE TABLE [TraceTri].[EMPLACEMENT](
	[NO_EMPLACEMENT] [INT] NOT NULL,
	[DATE_CREATION] [DATETIME] NOT NULL,
	[CODE_EMPLACEMENT] [VARCHAR](50) NOT NULL,
	[LIBELLE] [VARCHAR](50) NULL,
	[DATE_AFFECTATION] [DATETIME] NULL
 CONSTRAINT [PK_EMPLACEMENT] PRIMARY KEY CLUSTERED 
(
	[NO_EMPLACEMENT] ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
) ON [PRIMARY]

[Boubou2020]

a Chaque fois que vous obtenez une syntaxe incorrecte l'exception s’apparaît , il est préférable d'aller et attentivement votre code et vérifier que toutes les déclarations sont bien formés et complète. Habituellement,je ne peux pas vous aider sans le syntaxe correcte pour l'opération qui commence par insert (voir le profiler) , car il est très spécifique à votre code. Une bonne approche pour trouver la faute est pour localiser le point de l'erreur

[elsuket]

Alternativement, vous pouvez encadrer la requête en question d'un contrôle TRY et d'une transaction explicite. Par 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
15
16
17
BEGIN TRY;
	BEGIN TRANSACTION;
		<votre requête>
	ROLLBACK TRANSACTION;
END TRY;
BEGIN CATCH;
	DECLARE @err_msg nvarchar(2048) = ERROR_MESSAGE();
		, @err_num int = ERROR_NUMBER();
		, @err_stt int = ERROR_STATE();
 
	IF XACT_STATE() <> 0;
	BEGIN;
		ROLLBACK TRANSACTION;
	END;
 
	THROW @err_num, @err_msg, @err_stt;
END CATCH;

De cette façon vous pouvez rejouer la requête pour voir où elle plante précisément.
Si elle vient à s’exécuter sans lever une exception, les modifications qu'elle aura entrainé seront annulées.

@++

[SQLpro]

1) utilisez vous le réplication de données ?
2) utilisez vous des colonnes ayant pour type TIMESTAMP ?
3) quel est la valeur de @@OPTIONS ?
4) vos bases de données système sont-elles au même niveau de compatibilité ?
5) avez-vous plusieurs instances de SQL Server sur cette machine ?
6) quel est la collation du serveur et de la base de production ?
7) avec quel outil avez vous édité vos procédures stockées ?

A +

[Batou69]

Bonjour

1) utilisez vous le réplication de données ?
2) utilisez vous des colonnes ayant pour type TIMESTAMP ?
3) quel est la valeur de @@OPTIONS ?
4) vos bases de données système sont-elles au même niveau de compatibilité ?
5) avez-vous plusieurs instances de SQL Server sur cette machine ?
6) quel est la collation du serveur et de la base de production ?
7) avec quel outil avez vous édité vos procédures stockées ?

A +

1 : Oui. Réplication transactionnelle vers un autre serveur. L'erreur se produit sur le serveur de distribution (on est en mode push)
2 : non
3 : il me semble que les options peuvent être différentes pour chaque connexion.
J'ai capturé les connexions avec le profiler et sur toutes les options sont les mêmes :
-- network protocol: TCP/IP
set quoted_identifier on
set arithabort off
set numeric_roundabort off
set ansi_warnings on
set ansi_padding on
set ansi_nulls on
set concat_null_yields_null on
set cursor_close_on_commit off
set implicit_transactions off
set language Français
set dateformat dmy
set datefirst 1
set transaction isolation level read committed


4 : toutes les bases du serveur sont en niveau 120 SAUF la base distribution qui est en 90 (je n'ai aucune idée du pourquoi)
5 : non
6 : La collation est identique partout (bases système et la base de production) : French_CI_AS
7 : SSMS mais elles sont généralement codées en local puis transférées sur le serveur. Je ne sais pas comment vérifier si on a un problème d'encodage du fichier de départ....


Sur le serveur, nous avons de nombreux programmes connectés à la base. Seuls trois provoquent ces erreurs. De plus tous utilisent la même DLL pour l'accès à la base. Je cherche encore du coté du code, mais je ne vois pas de différence.....

[Batou69]

Je vais tester cela sur un exemple. Je pense pouvoir faire cela dans la journée.

Merci

[aieeeuuuuu]

Bonjour,

Il est possible aussi que ce soit l'applicatif qui, après appel des procédures stockées, lance une commande mal formée.
Car visiblement, les SP tournent bien et les exceptions surviennent après.

[Batou69]

Oui c'est possible, mais dans ce cas, pourquoi est ce que je ne la vois pas dans le profiler ?

[aieeeuuuuu]

cela dépend des évènements que vous profilez.
s'il vous ne profilez que les SP mais que la requête est exécutée directement, il est normal que vous ne la voyiez pas.

[Batou69]

Alternativement, vous pouvez encadrer la requête en question d'un contrôle TRY et d'une transaction explicite. Par 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
15
16
17
BEGIN TRY;
	BEGIN TRANSACTION;
		<votre requête>
	ROLLBACK TRANSACTION;
END TRY;
BEGIN CATCH;
	DECLARE @err_msg nvarchar(2048) = ERROR_MESSAGE();
		, @err_num int = ERROR_NUMBER();
		, @err_stt int = ERROR_STATE();
 
	IF XACT_STATE() <> 0;
	BEGIN;
		ROLLBACK TRANSACTION;
	END;
 
	THROW @err_num, @err_msg, @err_stt;
END CATCH;

De cette façon vous pouvez rejouer la requête pour voir où elle plante précisément.
Si elle vient à s’exécuter sans lever une exception, les modifications qu'elle aura entrainé seront annulées.

@++

Alors j'ai essayé votre requête (en corrigeant le premier rollback en un commit) et j'ai eu le message :

'Syntaxe incorrecte vers 'begin'

Donc quelle que soit l'instruction, l’exception est lancée

[Batou69]

Bon, j'ai finalement trouvé la cause alors je m'auto répond,

peut être que vous saurez m'expliquer le pourquoi :

Nos applications sont écrites en Qt4 et utilisent ODBC pour se connecter à la base.

L'erreur vient du type de curseur utilisé avant l'appel à la requête. Chaque appel à SQLExecDirectW est précédé d'un SQLSetStmtAttrW
avec comme paramètre SQL_ATTR_CURSOR_TYPE = SQL_CURSOR_STATIC ce qui provoque une erreur

Lorsqu'au contraire, j'effectue l'appel à SQLSetStmtAttrW avec SQL_ATTR_CURSOR_TYPE = SQL_CURSOR_FORWARD_ONLY
dans ce cas je n'ai pas d'erreur.

J'ai regardé la documentation des deux fonctions, et je n'ai pas trouvé clairement qu'il était interdit d'avoir un curseur statique pour un update... mais je comprend la logique.

Voila, en espérant que cela vienne en aide à quelqu'un..

A+