Discussion :

[SkYsO]

Bonjour à tous,

j'ai une requête de ce genre :

SELECT certains champs
FROM Table
WHERE ID_Table IN (1,2,5,8,7,9,...)

Je cherche à récupérer les informations que de certains enregistrements. le seul moyen que j'ai de cibler ces enregistrements sont les identifiants.

Le problème c'est qu'avec un certain nombre >6000 identifiants, j'ai cette erreur :

---------------------------
Microsoft SQL Server Management Studio Express
---------------------------
Mémoire insuffisante pour cette opération.
---------------------------
OK Aide
---------------------------

j'utilise une base sous SQLServer et j'ai exécuté la requête directement dans le SQL Manager.

Avez vous une idée ? est ce le fait de mettre trop d'identifiants ? ce qui lui demande trop de calcul ?
dois-je faire mes requêtes en plusieurs fois ? en découpant mes listes d'identifiant ?
Une autre requête possible ?

merci pour votre aide

[pacmann]

Ouah, sympa !
Bon, je ne pense pas que c'est SQL Server, mais juste l'interface.
J'ai trouvé une limite sur le nombre d'identifiants, mais c'est un peu plus long...
http://support.microsoft.com/kb/913050/fr

Ces identifiants sont dans un fichier ?
Tu peux peut être commencer par importer le fichier dans une table, puis faire la jointure ?

[miloux32]

Sur Oracle , je sais qu'il y a une limite au contenu du IN (s'il n'est pas issu d'un select) La limite est à 1000 en principe.


Genre

Code :

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

1
2
3
Select * from TABLE1 
where ident in ( 1,2,...1000,1001) 
=> ca plante

Code :

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

1
2
3
select * from TABLE1
where ident in ( Select ident from TABLE2 where ....) 
=> ca ne plante pas

Comment obtiens tu le contenu de ton IN ?

[SQLpro]

Code :

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

Mémoire insuffisante pour cette opération.

Signifie que vous n'avez pas assez de RAM pour effectuer cette opération. A ma connaissance il n'y a pas de limite de nombre dans un IN, juste la taille de la requête qui de mémoire ne doit pas dépasser 128 Mo de code en v 2000. Mais en v 2005 je crois que c'est bien plus.

D'autre part il y a un problème et sa correction à ce sujet :
http://support.microsoft.com/kb/912439/en-us

A +

[SkYsO]

Merci à tous pour vos réponses.

Alors, pour mon IN, j'obtiens les identifiants à partir d'une chaine. En fait dans mon programme Delphi, j'utilise des composants ADO et c'est une chaine qui est construite.
Pour être sur que cela ne vient pas de mon composant ou autre j'ai fais un copier coller dans le SQLServer.

Code :

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

1
2
SELECT * FROM TABLE1
WHERE ident IN ( SELECT ident FROM TABLE2 WHERE ....)

Et je peux mettre mes identifiants dans le WHERE ? ça va pas me faire la même chose ?

@sqlPro : je vais regarder pour ton lien, merci

Par contre si je remplace dans mon IN par un Select identifiant From Table sans rien de plus ça marche bien mais bon évidements je récupère trop d'enregistrement mais pas de soucis de mémoire.

[miloux32]

Par contre si je remplace dans mon IN par un Select identifiant From Table sans rien de plus ça marche bien mais bon évidements je récupère trop d'enregistrement mais pas de soucis de mémoire.

C'est donc la construction de la requete qui est trop grosse

regarde si tu peux pas regrouper certains identifiants ..
genre pas la peine de faire

Code :

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

ident in ( 1,2,3,4,5,6,7,8,9,10,11,12,13,15,35)

Fais plutot

Code :

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

ident <= 15 or ident = 35

ce genre de truc peut faire gagner un peu.

Enfin là ca reste de la bidouille quand même ....

[SkYsO]

C'est donc la construction de la requete qui est trop grosse

regarde si tu peux pas regrouper certains identifiants ..
genre par la peine de faire

Code :

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

ident in ( 1,2,3,4,5,6,7,8,9,10,11,12,13,15,35)

Fais plutot

Code :

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

ident <= 15 or ident = 35

ce genre de truc peut faire gagner un peu.

Enfin là ca reste de la bidouille quand même ....

Je ne peux pas faire ça car ma liste est vraiment aléatoire et je pense que le traitement sera trop lourd si je dois faire ça. Mais c'est peut être une solution après tout.

[miloux32]

Je ne peux pas faire ça car ma liste est vraiment aléatoire et je pense que le traitement sera trop lourd si je dois faire ça. Mais c'est peut être une solution après tout.

Ou alors la découper ....

[SkYsO]

Oui j'avais pensé à ça mais bon.

A oui sinon j'ai visité le lien SQLPro, le serveur de test actuel est SQLServer2000
Par contre j'utilise de temps en temps l'interface du 2005 pour l'exécution de requête.
Bref, y'a-t-il aussi un correctif sur 2000 ?

[pacmann]

Ta requête que tu exécutes par DELPHI, elle plante dans le programme ?
Dans ce cas, ça lève quelle exception ?
Parce qu'il se peut également qu'il y ait des limites sur les paramètres des méthodes qui exécutent le SQL dans le programme...

Si tel est le cas, tu peux insérer tes identifiants par paquets de [limite admissible] dans une table à 1 colonne, puis tu fais la jointure entre la table et la table temporaire...

[SkYsO]

Elle plante à l'ouverture, donc en fait c'est l'objet ADOQuery qui me renvoi l'erreur du SQLServer.
Mais bon exécuter la requête par paquet est aussi une solution que je vais garder en tête.

merci à tous


D'autres avis ?

[pacmann]

Et l'objet ADOQuery te renvoie la même Erreur que lorsque tu exécutes directement sur SQL server mangement ?

[SQLpro]

Il serait bien plus simple d'utiliser une table temporaire, faire l'insertion de toutes tes valeurs dedans, voir même indexer l'unique colonne, puis de lancer la requête....

Code :

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

CREATE TABLE #T (C INT)

puis :

Code :

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

1
2
3
4
INSERT INTO #T (C) VALUES (1);
INSERT INTO #T (C) VALUES (2);
INSERT INTO #T (C) VALUES (5);
...

puis :

Code :

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

CREATE INDEX XXX ON #T (C)

et enfin :

Code :

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

1
2
3
SELECT certains champs
FROM Table T
       INNER JOIN #T ON ID_Table = C

Non seulement ce serait plus élégant, mais aussi plus rapide et plus performant !

A +

[SkYsO]

@pacman, oui la même erreur.

@sqlPro : ça ne sera pas trop long de faire par exemple 6000 insert ? à la place de disons deux fois la requête avec 3000 ident dans le IN ?

[SQLpro]

Selon toi, qu'est ce qui sera plus rapide : faire un gros tas de 6000 rails et dire aux ouvrier d'aller chercher les rails du tas un a un pour construire la voie de chemin de fer dessus ou bien apporter chaque nouveau rail au moment ou l'on en a besoin à la place ou l'on doit le poser ?

Il y a encore plus rapide : faire des rails préassemblés en usine :
construire un fichier ou un flux de données (XML par exemple) côté client et le faire absorber par le serveur à l'aide d'un outil genre ETL...
Par exemple avec SQL Server en utilisant un flux XML mémoire et les procédures d'insertion du flux qui vont bien, ou alors créer un fichier sur disque et l'importer via la commande BULK INSERT.

A +

[SkYsO]

hum ok,

le côté XML aussi à l'air intéressant, je vais voir ce que je peux trouver. merci

[deltree]

Bonjour.
Est-ce que SQL est vraiment adapté?
est-ce que tu ne pourrais pas sélectionner plus de lignes, et refiltrer en logiciel (PHP, C Java, ou même peut-être XSL avec un rendu XML)

en prenant pour la sélection par exemple le min et le max des valeurs utilisée dans le "in".
d'ailleurs si tu as toutes ces valeurs de IN, tu as peut-être déjà fait la requête qui envoie davantage de lignes=> solution: conserver ce résultat.

[SkYsO]

je ne suis pas sûr que cela soit une bonne solution car si je me retrouve avec *100 d'enregistrement à parcourir ça risque de gâcher pas mal.