Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez longue).
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire à
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et je
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez longue).
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire à
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et je
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez longue).
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire à
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et je
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*
FROM MyTable, #TableTmp
WHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence) sur
le champ MyField-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
longue).Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
àpartir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
jerenvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*
FROM MyTable, #TableTmp
WHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence) sur
le champ MyField
-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
longue).
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
à
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
je
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*
FROM MyTable, #TableTmp
WHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence) sur
le champ MyField-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
longue).Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
àpartir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
jerenvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
Merci pour l'info.
Dans mon cas, le problème vient du fait que la liste des
données à placer dans la clause "IN" est, à la base, un
tableau (array) fourni par VB.
J'ai effectivement créé une table temporaire dans laquelle
j'insère (par boucle + recordset déconnecté) le contenu du
tableau mais la fonction ADO "UpdateBatch" prend trop de
temps (+/- 50 sec. pour une insertion de 15.000 lignes, je
sais que ce n'est pas énorme mais j'ai vraiment besoin
d'optimiser les perf.).
Ex. (de mémoire) dans Visual Basic (ADO) :
For lngLoop = 0 To Ubound(MyArray)
MyRst.Add
MyRst.Fields(0).Value = MyArray(lngLoop)
MyRst.Fields(1).Value = "Sequence"
Next
...
MyRst.UpdateBatch
La boucle ne prend pas beaucoup de temps (manip. des
données en mémoire uniquement).
Par contre la fonction "UpdateBatch" (écriture dans la BD
via le réseau) prend +/- 50 sec.
Une fois les données insérées, j'utilisais des
fonctions "UPDATE MyTable SET ... FROM MyTable A LEFT
OUTER JOIN MyTable1 B ON A.MyField = B.MyField ...
WHERE ..."-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*FROM MyTable, #TableTmpWHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence) sur
le champ MyField-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
longue).Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
àpartir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
jerenvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
Merci pour l'info.
Dans mon cas, le problème vient du fait que la liste des
données à placer dans la clause "IN" est, à la base, un
tableau (array) fourni par VB.
J'ai effectivement créé une table temporaire dans laquelle
j'insère (par boucle + recordset déconnecté) le contenu du
tableau mais la fonction ADO "UpdateBatch" prend trop de
temps (+/- 50 sec. pour une insertion de 15.000 lignes, je
sais que ce n'est pas énorme mais j'ai vraiment besoin
d'optimiser les perf.).
Ex. (de mémoire) dans Visual Basic (ADO) :
For lngLoop = 0 To Ubound(MyArray)
MyRst.Add
MyRst.Fields(0).Value = MyArray(lngLoop)
MyRst.Fields(1).Value = "Sequence"
Next
...
MyRst.UpdateBatch
La boucle ne prend pas beaucoup de temps (manip. des
données en mémoire uniquement).
Par contre la fonction "UpdateBatch" (écriture dans la BD
via le réseau) prend +/- 50 sec.
Une fois les données insérées, j'utilisais des
fonctions "UPDATE MyTable SET ... FROM MyTable A LEFT
OUTER JOIN MyTable1 B ON A.MyField = B.MyField ...
WHERE ..."
-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*
FROM MyTable, #TableTmp
WHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence) sur
le champ MyField
-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
longue).
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
à
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
je
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
Merci pour l'info.
Dans mon cas, le problème vient du fait que la liste des
données à placer dans la clause "IN" est, à la base, un
tableau (array) fourni par VB.
J'ai effectivement créé une table temporaire dans laquelle
j'insère (par boucle + recordset déconnecté) le contenu du
tableau mais la fonction ADO "UpdateBatch" prend trop de
temps (+/- 50 sec. pour une insertion de 15.000 lignes, je
sais que ce n'est pas énorme mais j'ai vraiment besoin
d'optimiser les perf.).
Ex. (de mémoire) dans Visual Basic (ADO) :
For lngLoop = 0 To Ubound(MyArray)
MyRst.Add
MyRst.Fields(0).Value = MyArray(lngLoop)
MyRst.Fields(1).Value = "Sequence"
Next
...
MyRst.UpdateBatch
La boucle ne prend pas beaucoup de temps (manip. des
données en mémoire uniquement).
Par contre la fonction "UpdateBatch" (écriture dans la BD
via le réseau) prend +/- 50 sec.
Une fois les données insérées, j'utilisais des
fonctions "UPDATE MyTable SET ... FROM MyTable A LEFT
OUTER JOIN MyTable1 B ON A.MyField = B.MyField ...
WHERE ..."-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*FROM MyTable, #TableTmpWHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence) sur
le champ MyField-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (->
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide mais
l'opération de mise à jour (UpdateBatch) est assez
longue).Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table temporaire
àpartir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire et
jerenvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui contiendrait
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
-----Original Message-----
créé un fichier texte et insert le d'un seul coup dans ta
temporaire à l'aide de Bulk Insert.
A +
Olivier a écrit:Merci pour l'info.
Dans mon cas, le problème vient du fait que la liste
données à placer dans la clause "IN" est, à la base, un
tableau (array) fourni par VB.
J'ai effectivement créé une table temporaire dans
j'insère (par boucle + recordset déconnecté) le contenu
tableau mais la fonction ADO "UpdateBatch" prend trop
temps (+/- 50 sec. pour une insertion de 15.000 lignes,
sais que ce n'est pas énorme mais j'ai vraiment besoin
d'optimiser les perf.).
Ex. (de mémoire) dans Visual Basic (ADO) :
For lngLoop = 0 To Ubound(MyArray)
MyRst.Add
MyRst.Fields(0).Value = MyArray(lngLoop)
MyRst.Fields(1).Value = "Sequence"
Next
...
MyRst.UpdateBatch
La boucle ne prend pas beaucoup de temps (manip. des
données en mémoire uniquement).
Par contre la fonction "UpdateBatch" (écriture dans la
via le réseau) prend +/- 50 sec.
Une fois les données insérées, j'utilisais des
fonctions "UPDATE MyTable SET ... FROM MyTable A LEFT
OUTER JOIN MyTable1 B ON A.MyField = B.MyField ...
WHERE ..."-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*FROM MyTable, #TableTmpWHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence)
le champ MyField-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (-2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide
l'opération de mise à jour (UpdateBatch) est assez
longue).Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table
àpartir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire
jerenvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server /
Livre SQL - col. Référence :
Le site du SQL, pour débutants et pros :
****************** mailto:
.
-----Original Message-----
créé un fichier texte et insert le d'un seul coup dans ta
temporaire à l'aide de Bulk Insert.
A +
Olivier a écrit:
Merci pour l'info.
Dans mon cas, le problème vient du fait que la liste
données à placer dans la clause "IN" est, à la base, un
tableau (array) fourni par VB.
J'ai effectivement créé une table temporaire dans
j'insère (par boucle + recordset déconnecté) le contenu
tableau mais la fonction ADO "UpdateBatch" prend trop
temps (+/- 50 sec. pour une insertion de 15.000 lignes,
sais que ce n'est pas énorme mais j'ai vraiment besoin
d'optimiser les perf.).
Ex. (de mémoire) dans Visual Basic (ADO) :
For lngLoop = 0 To Ubound(MyArray)
MyRst.Add
MyRst.Fields(0).Value = MyArray(lngLoop)
MyRst.Fields(1).Value = "Sequence"
Next
...
MyRst.UpdateBatch
La boucle ne prend pas beaucoup de temps (manip. des
données en mémoire uniquement).
Par contre la fonction "UpdateBatch" (écriture dans la
via le réseau) prend +/- 50 sec.
Une fois les données insérées, j'utilisais des
fonctions "UPDATE MyTable SET ... FROM MyTable A LEFT
OUTER JOIN MyTable1 B ON A.MyField = B.MyField ...
WHERE ..."
-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*
FROM MyTable, #TableTmp
WHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence)
le champ MyField
-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (-
2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide
l'opération de mise à jour (UpdateBatch) est assez
longue).
Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table
à
partir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire
je
renvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server /
Livre SQL - col. Référence :
Le site du SQL, pour débutants et pros :
****************** mailto:brouardf@club-internet.fr
.
-----Original Message-----
créé un fichier texte et insert le d'un seul coup dans ta
temporaire à l'aide de Bulk Insert.
A +
Olivier a écrit:Merci pour l'info.
Dans mon cas, le problème vient du fait que la liste
données à placer dans la clause "IN" est, à la base, un
tableau (array) fourni par VB.
J'ai effectivement créé une table temporaire dans
j'insère (par boucle + recordset déconnecté) le contenu
tableau mais la fonction ADO "UpdateBatch" prend trop
temps (+/- 50 sec. pour une insertion de 15.000 lignes,
sais que ce n'est pas énorme mais j'ai vraiment besoin
d'optimiser les perf.).
Ex. (de mémoire) dans Visual Basic (ADO) :
For lngLoop = 0 To Ubound(MyArray)
MyRst.Add
MyRst.Fields(0).Value = MyArray(lngLoop)
MyRst.Fields(1).Value = "Sequence"
Next
...
MyRst.UpdateBatch
La boucle ne prend pas beaucoup de temps (manip. des
données en mémoire uniquement).
Par contre la fonction "UpdateBatch" (écriture dans la
via le réseau) prend +/- 50 sec.
Une fois les données insérées, j'utilisais des
fonctions "UPDATE MyTable SET ... FROM MyTable A LEFT
OUTER JOIN MyTable1 B ON A.MyField = B.MyField ...
WHERE ..."-----Original Message-----
Salut
Dans ton cas de figure il est souvent possible de
substituer une sous-req IN par une équijointure
SELECT MyTable.*FROM MyTable, #TableTmpWHERE MyTable.MyField = #TableTmp.AutreField
Tu y gagneras NETTEMENT en performance.
Cela dit, comme l'indique l'autre Fred, tu as grand
intéret à poser un index (non ordonné de préférence)
le champ MyField-----Message d'origine-----
Je désire connaitre les limitations d'une clause "IN" :
SELECT * FROM MyTable WHERE MyField IN (...)
En pratique, je reçois (de VB) un tableau d'éléments (-2500) que j'insère dans une table temporaire (par
l'intermédiaire d'une boucle et d'un recordset
déconnecté ; le traitement de la boucle est rapide
l'opération de mise à jour (UpdateBatch) est assez
longue).Une fois cette table temporaire peuplée, je réalise
diverses action de mise à jour de cette table
àpartir de données contenues dans d'autres tables.
Lorsque tous les traitements utiles ont été réalisés,
j'ouvre un recordset basé sur cette table temporaire
jerenvoie l'info. en réponse au client.
Mon objectif est d'éviter ce traitement "lourd" en
utilisant, si possible, une clause "IN" qui
les +/- 2500 éléments du tableau.
Est-ce possible ? Quelles sont les performances ?
.
.
--
Frédéric BROUARD - expert SQL, spécialiste : SQL Server /
Livre SQL - col. Référence :
Le site du SQL, pour débutants et pros :
****************** mailto:
.