Discussion :

[Pol63]

bonjour

j'ai un trigger instead of insert qui plante, j'ai réduit le code pour mettre le problème en évidence :

Code :

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

1
2
3
4
5
6
7
8
9
ALTER TRIGGER [dbo].[GestionHistoriqueInsteadOfInsertArticleCompartiment] ON [dbo].[ArticleCompartiment] INSTEAD OF INSERT
AS
BEGIN
 
SELECT TOP 1 * INTO #aInserer FROM ArticleCompartiment
DELETE FROM #aInserer
INSERT INTO ArticleCompartiment SELECT * FROM #aInserer
 
END

à l'origine je voulais créé une table temporaire dans laquelle je mets inserted
je fais des modifs dans cette table temporaire
en enfin je fait rentrer ce qu'il y a dans cette temporaire dans la vraie table
(les triggers récursifs sont désactivés sur la base)

le code restant et qui bug encore c'est la création de la table # à l'identique de la vraie table (je la vide pour que ca n'insert rien, le problème ne vient pas des données)
puis je reverse dans la vraie table
(j'ai dejà plusieurs triggers dans le genre, les autres fonctionnent

et le message d'erreur est :
Msg*213, Niveau*16, État*1
Erreur INSERT*: le nom ou le numéro de colonne des valeurs fournies ne correspond pas à la définition de la table.

j'ai essayé plusieurs méthodes meme en créant la table # avec un create table et en nommant les champs comme la vraie table, ca me mets un message d'erreur par colonne en disant qu'elle existe pas

si quelqu'un peut m'aider parce que là franchement je vois pas du tout comment remédier à ca

merci

[elsuket]

Bonsoir,

Il y a quelque chose que je ne comprends pas :

- SELECT TOP 1 * INTO #aInserer FROM ArticleCompartiment : Vous insérez une ligne de données dans une table temporaire
- DELETE FROM #aInserer : vous les supprimez ensuite, donc votre table temporaire est vide
- INSERT INTO ArticleCompartiment SELECT * FROM #aInserer : par conséquent vous n'insérez rien dans votre table ArticleCompartiment.

En tout état de cause, le mieux reste d'utiliser le moins possible les tables temporaires, et encore moins dans les triggers. Rappelez-vous que le code qui est dans votre trigger fait partie, lors de l'exécution d'une insertion par une procédure stockée appelante, de la même transaction.

Je suis persuadé que vous pouvez faire vos modifications directement depuis INSERTED. Quelles modifications voulez-vous faire ?

A+

[Pol63]

vous etes pas très au point on dirait

deja j'ai expliqué que le code ici était pour ne laisser que ce qui est necessaire à comprendre le bug, je sais que j'insere rien, le vrai code n'est pas ca, mais celui ci plante aussi

les tables temporaires c'est très utile y a plein de choses qu'on ne peut pas faire sinon (ou de manière moins propre, et parfois beaucoup moins rapide)


et la table inserted (ou deleted) n'est pas modifiable ...

[elsuket]

Bonjour,

vous etes pas très au point on dirait

C'est fort probable. En revanche si vous l'étiez plus que moi, vous sauriez qu'il faut avoir recours le moins possible aux tables temporaires, et qu'il vaut 100 fois mieux utiliser du code ensembliste.

[Pol63]

arguments ??

[Jinroh77]

Les tables temporaire ne se retrouvent-elles pas dans la tempDB et par la même occasion sur le disque physique (non en RAM) ?

[Pol63]

dans le pire des cas c'est pas bien grave ca

enfin dans un cas de trigger instead of insert, il est à mon avis souvent impossible de faire autrement que d'avoir des tables # (ca depend du traitement certes)

les tables temporaires permettent aussi d'avoir une table par connexion, pour faire les meme traitements mais chacun le sien

et ca permet dans des traitements compliqués de gagner des performances

de plus elles se suppriment toutes seules, pratique aussi en cas de crash ou autre

[elsuket]

Bonsoir,

Les tables temporaire ne se retrouvent-elles pas dans la tempDB

Si, c'est exact

les tables temporaires permettent aussi d'avoir une table par connexion

Donc selon vous, quand j'exécute une requête, vous en utilisant une autre connexion, vous pouvez modifier les valeurs variables de la procédure stockée que je suis en train d'exécuter ?

de plus elles se suppriment toutes seules, pratique aussi en cas de crash ou autre

Et en cas d'échec de la transaction ?

Prenons un petit batch tout simple :

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
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
SET STATISTICS TIME ON
GO
 
SET NOCOUNT ON
GO
 
DROP TRIGGER TR_IOFI_TbTEST
GO
 
CREATE TRIGGER TR_IOFI_TbTEST
	ON dbo.TbTEST
INSTEAD OF INSERT
AS
BEGIN
	PRINT '===========> Début trigger avec table temporaire'
	SELECT *
	INTO #TEST
	FROM inserted
 
	UPDATE #TEST
	SET nTest = nTest * 2
 
	INSERT INTO dbo.TbTEST
	SELECT * 
	FROM #TEST
 
	DROP TABLE #TEST
	PRINT '===========> Fin trigger avec table temporaire'
END
GO
 
PRINT '===========> Fin Creation trigger avec table temporaire'
GO
 
PRINT '===========> Début insertion avec table temporaire'
GO
 
INSERT INTO dbo.TbTEST (nTest) VALUES(1)
GO
 
PRINT '===========> Fin insertion avec table temporaire'
GO
 
DROP TRIGGER TR_IOFI_TbTEST
GO
 
PRINT '===========> Suppression trigger avec table temporaire'
GO
 
CREATE TRIGGER TR_IOFI_TbTEST
	ON dbo.TbTEST
INSTEAD OF INSERT
AS
BEGIN
	PRINT '===========> Début trigger sans table temporaire'
	INSERT INTO dbo.TbTEST
	SELECT nTest * 2
	FROM inserted
	PRINT '===========> Fin trigger sans table temporaire'
END
GO
 
PRINT 'Fin creation trigger sans table temporaire'
GO
 
PRINT '===========> Début insertion sans table temporaire'
GO
 
INSERT INTO dbo.TbTEST (nTest) VALUES(1)
GO
 
PRINT '===========> Fin insertion sans table temporaire'
GO

Si j'extrais de la trace qu'on obtient en fin d'exécution les temps d'exécution des triggers, j'obtiens, pour le trigger avec table temporaire :

===========> Début trigger avec table temporaire

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 1*ms.

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 17*ms.

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 1*ms.

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 9*ms.

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 1*ms.
===========> Fin trigger avec table temporaire


Et pour le trigger sans table temporaire:

===========> Début trigger sans table temporaire

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 1*ms.

SQL Server \endash Temps d'exécution*:
, Temps UC = 0*ms, temps écoulé = 1*ms.
===========> Fin trigger sans table temporaire

Et ceci avec un jeu de données tout petit. Imaginez ce que cela peut devenir avec un jeu de données normal ...

Je vous passe les temps de compilation, du même acabit, mais je vous donne quand même les temps d'insertion :
- Avec table temporaire : 28ms
- Sans table temporaire : 9ms

Vous stockez dans une autre base de données, système et pas des moins influentes sur les performances globables de vos BD, des données que vous avez déjà en mémoire.
Donc vous forcez SQL Server à écrire des pages alors que vous avez déjà tout sous la main. Voilà pourquoi c'est plus lent.

[Pol63]

Donc selon vous, quand j'exécute une requête, vous en utilisant une autre connexion, vous pouvez modifier les valeurs variables de la procédure stockée que je suis en train d'exécuter ?

je ne vois pas du tout le rapport ...




biensur que dans le cas d'un trigger une table temporaire à l'intérieur va ralentir
je dis que ca gagne des perfs sur des traitements, plutot que d'extraire 100x des données dans une procédure stockée, les mettre de coté dans une table temporaire gagne du temps


vous faites de la désinformation totale....

[elsuket]

Bonsoir,

Le rapport vient de ceci :

les tables temporaires permettent aussi d'avoir une table par connexion

Lorsque vous exécutez une procédure stockée, SQL Server vous ouvre une connexion, et les variables ou les tables temporaires locales (parce que les ## existent aussi et que ses données peuvent être partagées par plusieurs connexions) manipulées dans cette connexion n'appartiennent qu'à celle-ci : c'est l'intégrité.

biensur que dans le cas d'un trigger une table temporaire à l'intérieur va ralentir
je dis que ca gagne des perfs sur des traitements, plutôt que d'extraire 100x des données dans une procédure stockée, les mettre de coté dans une table temporaire gagne du temps

Vous vous contredites avec :

et ca permet dans des traitements compliqués de gagner des performances

Quelle différence faites-vous entre un trigger et une procédure stockée ?
Un trigger est un cas particulier de procédure stockée qui s'exécute lors de la survenance d'un évènement dans une base de données ou sur un serveur.

Dans certains cas, je suis d'accord avec vous, il est difficile de se passer de tables temporaires.
Mais la plupart du temps, les requêtes qui utilisent des tables temporaires sont ré-écrivables avec du code ensembliste (tables dérivées et expressions de table commune ou CTE depuis SQL Server 2005)

Faites le test et vous verrez : c'est retournant

vous faites de la désinformation totale....

Donc désinformer, c'est informer, preuve à l'appui, que quelque chose est vrai .
J'ai fait la même erreur que vous, ne vous inquiétez pas. Après je me suis rendu compte que c'est contre-performant ...

[Pol63]

arretez de chercher la petite bete à faire celui qui comprends pas
biensur dans trigger qui fait rien la table # ralentie
mais je vous parles de traitement (qu'il soit dans un trigger ou non)
je ne me suis contredit en rien

je ne vois pas le rapport non plus avec les tables ##

et pas non plus avec vos liens, je vois pas le rapport des requetes récursives avec les table temporaires ...


j'abandonne dans l'idée de vous raisonner, vous etes à coté du sujet qu'est une table #


encore un qui connait la théorie et pas la pratique ... et je sais à quel désastre ca peut mener sur des grosses applications ...

[elsuket]

Le pauvre ...

[Pol63]

ai je dis que je savais pas qu'elle était dans la tempDB ?

est ce moi qui ai hésité sur ce point ??


depuis le début vous hallucinez sérieusement
ou alors vous trollez pour me faire chier je sais pas ...

[elsuket]

Pas content

[SQLpro]

les tables temporaires c'est très utile y a plein de choses qu'on ne peut pas faire sinon (ou de manière moins propre, et parfois beaucoup moins rapide)

Contrairement à, ce que vous affirmez, on peut se passer totalement de toute table temporaire à l'aide de simples requêtes SQL (SQL:1999 / SQL:2003). Ce sera toujours plus rapide, car le travail va s'effectuer en RAM alors que des tables temporaires obligent à des opérations d'écriture disque.

A +

[Pol63]

j'aimerais bien savoir pourquoi les choses temporaires ne seraient pas traitées en ram ???
si c'est temporaire c'est justement qu'on en a pas besoin plus que ca ...

et des opérations d'écriture sur une table nécessite à mon avis des accès disques (là aussi je veux bien qu'on me ptrouve le contraire)

si c'est rellement le cas, je suis vraiment curieux de savoir ce qui a motivé ce choix !


sinon je peux me justifier sur le fait de raisonner avec la logique en cas de défaut de connaissances (certes sur des choses complexes comme un sgbd vous allez dire que ca ma dépasse surement mais bon ... des données temporaires pas en ram ...)

[SQLpro]

Je vous cite :

des opérations d'écriture sur une table nécessite à mon avis des accès disques

OUI !

Une table temporaire étant une table, elle est instanciée en tant que table et bénéficie des mêmes mécanismes de persistance que n'importe quelle autre table.
Comme une table temporaire peut perdurez tant que la session est vivante, imaginez ce qui se passerait si les tables temporaires n'existaient qu'en RAM... Prenons un utilisateur qui se connecterait à 8h du matin pour terminer sa session (déconnexion) à 18h après avoir créé 2 500 tables temporaires de 500 000 lignes chacune... A votre avis dans quel état serait la RAM ???

certes sur des choses complexes comme un sgbd vous allez dire que ca ma dépasse surement mais bon ... des données temporaires pas en ram ...

A l'évidence, cela vous dépasse de beaucoup ! Mais ne vous en faites pas. Le niveau de connaissance moyen des informaticiens français est assez lamentable en matière de SGBDR. Disons que vous êtes dans la moyenne basse et que je vous donne la possibilité de vous élever...

A +

[Pol63]

Une table temporaire étant une table, elle est instanciée en tant que table et bénéficie des mêmes mécanismes de persistance que n'importe quelle autre table.
Comme une table temporaire peut perdurez tant que la session est vivante, imaginez ce qui se passerait si les tables temporaires n'existaient qu'en RAM... Prenons un utilisateur qui se connecterait à 8h du matin pour terminer sa session (déconnexion) à 18h après avoir créé 2 500 tables temporaires de 500 000 lignes chacune... A votre avis dans quel état serait la RAM ???

euh non, je ne suis pas idiot à ce point là quand même

Contrairement à, ce que vous affirmez, on peut se passer totalement de toute table temporaire à l'aide de simples requêtes SQL (SQL:1999 / SQL:2003). Ce sera toujours plus rapide, car le travail va s'effectuer en RAM alors que des tables temporaires obligent à des opérations d'écriture disque.

je dis juste qu'elles ont le droit à la ram autant que les tables normales,
certes les tables # on est bien obliger de les remplirs, mais dans certains traitement, vaut mieux les remplir une fois que chercher dans des 10aines de tables une multitude de fois

vous allez encore rebondir sur les index j'imagine mais bon ...

Le niveau de connaissance moyen des informaticiens français est assez lamentable en matière de SGBDR

c'est juste pour stocker des données pour notre programme
lol
c'est sur que c'est un domaine assez vaste, et j'ai encore à apprendre

[SQLpro]

mais dans certains traitement, vaut mieux les remplir une fois que chercher dans des 10aines de tables une multitude de fois

Encore une fois NON !
Approche simpliste à courte vue.

En alimentant une table temporaire avec des données qui existe déjà vous obligez que la RAM contienne à un moment donné deux fois les données. Autrement dit si vous avez 1 Go de RAM et une table de 1 Go que vous versez dans une table temporaire de 1 Go, il vous faudra utiliser la pagination avec de nombreuses écritures disque pour arriver à vos fin. Donc dégradation sévère des performances.

Vous avez visiblemnt encore BEAUCOUP BEAUCOUP de choses à apprendre avant d'affirmer !!!

A +

[Pol63]

arretez d'etre si aggresif
je disais ca avant d'avoir lu votre article
et je comprends maintenant que techniquement ca doit etre aussi rapide voir mieux de faire des jointures
mais là ou je bossais avant, on avait des tables minables (clés varchar pas ordonnées entre autre) et donc c'est surement pour ca que les tables temporaires nous permettaient de gagner en performances
parce qu'on a fait des tests via sql profiler et y avait pas photo ...