Discussion :

[nox75]

Bonjour,

j'ai le problème suivant :
J'ai un curseur, et dans mon WHILE sur le @@FETCH_STATUS, j'execute une instruction INSERT

Code :

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

1
2
3
4
5
6
7
8
 
FETCH CursInstruction INTO @Temp
 
WHILE @@FETCH_STATUS = 0
BEGIN
  INSERT INTO ##SCRIPT VALUES (@Temp)
  FETCH NEXT FROM CursInstruction INTO @Temp
END

Or je remarque que les Insert ne se font pas dans l'ordre. Quand la variable @Temp (de type VARCHAR(MAX)) contient un volume important, son insertion se fait parfois avec 3 ou 4 occurences de retard.
Ca me donne donc quelque chose comme :

Code :

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

1
2
3
4
5
6
7
8
 
FETCH met la valeur Instruction1 dans @Temp
INSERT INTO ##SCRIPT VALUES(Instruction1)
FETCH met la valeur Instruction2 dans @Temp
FETCH met la valeur Instruction3 dans @Temp
INSERT INTO ##SCRIPT VALUES(Instruction3)
FETCH met la valeur Instruction4 dans @Temp
INSERT INTO ##SCRIPT VALUES(Instruction2)

etc...

Y'a-t-il une solution pour forcer les insert à attendre la fin de l'insert précédent pour s'executer ?

Merci d'avance !

[cmako]

Comment tu fais pour afficher ça :

Code :

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

1
2
3
4
5
6
7
FETCH met la valeur Instruction1 dans @Temp
INSERT INTO ##SCRIPT VALUES(Instruction1)
FETCH met la valeur Instruction2 dans @Temp
FETCH met la valeur Instruction3 dans @Temp
INSERT INTO ##SCRIPT VALUES(Instruction3)
FETCH met la valeur Instruction4 dans @Temp
INSERT INTO ##SCRIPT VALUES(Instruction2)

Et c'est quoi ##Script, c'est une table?

[nox75]

Oui, c'est une table (temporaire).
En fait je n'affiche pas, c'est juste en faisant un select * dans ma table ##SCRIPT (qui ne contient qu'une colonne), mes instructions ne sont pas dans l'ordre. Alors que si je ne m'abuse, le select devrait par défaut renvoyer les lignes ordonnées par date d'insertion dans la table, non ?

[cmako]

Oui, c'est une table (temporaire).
En fait je n'affiche pas, c'est juste en faisant un select * dans ma table ##SCRIPT (qui ne contient qu'une colonne), mes instructions ne sont pas dans l'ordre. Alors que si je ne m'abuse, le select devrait par défaut renvoyer les lignes ordonnées par date d'insertion dans la table, non ?

C'est faux !! Avec une colonne et sans index cluster tout sera dans le désordre.
Pour que tes lignes apparaissent dans l'ordre il faut 2 colonnes.

[nox75]

J'ai ajouté une colonne, le problème reste le même.
Sinon tant pis j'ajoute une colonne que j'incrémente à chaque insert, et j'order by dessus dans mon select : /

[agemis31]

Bonjour,

A mon humble avis, index ou pas, il faut trier.

@+

[cmako]

Bonjour,

A mon humble avis, index ou pas, il faut trier.

@+

Lorsqu'on fait un SELECT * FROM matable les lignes n'apparaissent pas dans l'ordre cluster?
Il fait pourtant bien un Clustered index scan ?!

[nox75]

Ben c'est ce que je pensais aussi

[elsuket]

Bonjour,

Une première chose : en SQL l'ordre n'existe pas, ni pour les lignes, ni pour les colonnes.

La table (temporaire ou pas) de Nox75 n'étant pas indexée en cluster, les lignes sont donc retournées dans l'ordre de leur insertion.
Si la table est ordonnée en cluster, alors les lignes sont retournées dans l'ordre physique de la valeur de la clé qui compose l'index cluster.

Si nous exécutons :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
CREATE TABLE #TEST
(
	chaine VARCHAR(50)
)
 
INSERT INTO #TEST VALUES ('A')
INSERT INTO #TEST VALUES ('C')
INSERT INTO #TEST VALUES ('B')
INSERT INTO #TEST VALUES ('D')
 
SELECT *
FROM #TEST

Nous avons bien :

A
C
B
D

Si à la suite de ce lot nous exécutons :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
TRUNCATE TABLE #TEST
 
CREATE CLUSTERED INDEX IXC_TEST_chaine
ON #TEST (chaine)
 
INSERT INTO #TEST VALUES ('A')
INSERT INTO #TEST VALUES ('C')
INSERT INTO #TEST VALUES ('B')
INSERT INTO #TEST VALUES ('D')
 
SELECT *
FROM #TEST

Nous obtenons :

A
B
C
D

Enfin les curseurs peuvent globalement être évités en les remplaçant par des traitements ensemblistes.
Vous pourrez voir ici la différence en vitesse de traitement.

Nox75, quelle requête SELECT exécutez-vous pour lire votre table de trace ?

@++

[agemis31]

Bonjour,

Ma réponse n'était pas claire Je voulais juste dire que si l'on veut un résultat ordonné, il faut le demander, usuellement à l'aide d'un ORDER BY, ce qui à l'avantage d'être déclaratif et lisible.
Que SQL Serveur renvoie les lignes d'une table possédant un index clustered dans l'ordre de l'index si on omet de trier me semble résulter plus d'une logique d'efficacité que d'une règle.

Un petit lien intéressant sur ce sujet.

@+

[nox75]

Nox75, quelle requête SELECT exécutez-vous pour lire votre table de trace ?

Un simple "select * from ##Script"
D'après vos réponses, j'en déduis que mon select me renvoie bien les lignes dans l'ordre d'insertion. J'en conclue donc qu'écrire :
Insert into ##Script values (@var1)
Insert into ##Script values (@var2)
Insert into ##Script values (@var3)
ne garantit pas qu'on aura en table l'ordre @var1, @var2, @var3, si les variables ne contiennent pas la même quantité d'information.
Si @var1 contient 2000 caractères, et si @var2 n'en contient que 2 ou 3, il est possible que l'insertion de @var1 mette plus de temps, et que @var1 apparaîsse APRES @var2 dans la table.

Vrai ?

[agemis31]

Bonjour nox75,

D'après vos réponses, j'en déduis que mon select me renvoie bien les lignes dans l'ordre d'insertion

Je me demande bien comment vous arrivez à en déduire ça!
Le curseur est procédural et synchrone. Il faut distinguer l'ordre d'insertion, temporel, forcément, puisque vous ajoutez une ligne à la fois via votre curseur, et l'ordre de restitution. Il n'y a pas d'ordre de restitution par défaut quand on requête une table.

@+

[elsuket]

Votre table n'étant pas très volumineuse, il est bizarre que les lignes ne vous soient pas retournées dans l'ordre de leur insertion.
Effectueriez-vous des DELETE sur cette table ? parce que si tel est le cas, l'espace libéré par un tel ordre est réutilisé pour des insertions futures si la table n'est pas clusterisée.

La solution directe à votre problème, c'est d'ajouter à votre table temporaire une colonne avec la propriété de compteur, puis de la requêter en écrivant ORDER BY maColonneCompteur.

La vraie solution, c'est de n'utiliser ni les tables temporaires, ni les curseurs

@++

[nox75]

Bonjour nox75,



Je me demande bien comment vous arrivez à en déduire ça!
Le curseur est procédural et synchrone. Il faut distinguer l'ordre d'insertion, temporel, forcément, puisque vous ajoutez une ligne à la fois via votre curseur, et l'ordre de restitution. Il n'y a pas d'ordre de restitution par défaut quand on requête une table.

@+

Je me basais sur la réponse de Elsuket, un peu plus haut. D'après cette réponse, l'ordre par défaut d'un select correspond bien à l'ordre d'insertion dans la table. Ou alors je n'ai rien compris : /

Votre table n'étant pas très volumineuse, il est bizarre que les lignes ne vous soient pas retournées dans l'ordre de leur insertion.
Effectueriez-vous des DELETE sur cette table ? parce que si tel est le cas, l'espace libéré par un tel ordre est réutilisé pour des insertions futures si la table n'est pas clusterisée.

La solution directe à votre problème, c'est d'ajouter à votre table temporaire une colonne avec la propriété de compteur, puis de la requêter en écrivant ORDER BY maColonneCompteur.

La vraie solution, c'est de n'utiliser ni les tables temporaires, ni les curseurs

@++

Je ne fais pas de delete, uniquement des insert.
Je pourrai envoyer la procédure complète demain si vous le souhaitez. J'ai résolu le problème avec une colonne compteur, effectivement, mais je serai tout de meme curieux de connaître la cause de ce problème.
C'est une procédure qui génère un script de mise à jour des procédures stockées/fonctions/triggers/vues d'une base.

[SQLpro]

Je me basais sur la réponse de Elsuket, un peu plus haut. D'après cette réponse, l'ordre par défaut d'un select correspond bien à l'ordre d'insertion dans la table. Ou alors je n'ai rien compris : /

Erreur : Il n'y a JAMAIS de garantie d'ordre sans clause ORDER BY !

Relisez le post que j'ai écrit à ce sujet : http://blog.developpez.com/sqlpro/p5...sont-des-ense/

A +

[nox75]

Merci SQLPro

je suis en pleine relecture, mais ce que je don't get, c'est que je retrouve partout cette idée qu'avec une table simple (une seule colonne, pas de clé, pas d'index etc...) et juste des insert (aucun delete), le select renvoie les lignes dans l'ordre d'insertion. C'était je crois le sens du post d'elsuket, et c'est ce que je retrouve dès le début de ton exemple ici :

Code :

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

1
2
3
4
5
6
7
8
9
10
11
12
 
SELECT C, D FROM T_LIGNES 
 
C           D 
----------- ---------------- 
1           Z                
2           Y                
3           X                
4           W                
5           V          
 
Apparament les lignes sont dans l'ordre d'insertion

C'est donc un pur hasard ?
Il serait donc possible de reprendre exactement le premier exemple tout à fait basique de votre post explicatif, et d'obtenir un select renvoyant les lignes dans un ordre différent ?

Si non, pourquoi est-ce que je n'obtiens pas ce résultat dans mon cas ?

[SQLpro]

C'est donc un pur hasard ?

Oui. Même si en pratique dans 95% des cas SQL Server renverra les données dans l'ordre d'insertion, vous ne pouvez ni devez compter sur cela !

A +

[nox75]

Ok !

Ce point est donc réglé, j'utilise une colonne compteur et j'ajoute un Order by dans ma requête.

Merci à tous pour votre aide et vos explications