Je dois importer les données d'un fichier texte dans une table de base de
données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en
avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou 40
000 fiches (je teste à 100 000).
H1:
Je récupère les id du fichier un par un (en boucle) puis supprime la fiche
dans la BD. Enfin j'insère une par une les fiches contenues dans le fichier
vers la BD.
Bien mais trop long en traitement.
H2:
J'imagine de créer un recordset déconnecté dans lequel j'insère les données.
Ensuite à partir de celui-ci je supprime les fiches (requête DELETE
matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon
j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation.
Pourtant ce serait la solution.
H3:
Je crée une table dans la BD, j'insère une par une les fiches contenues dans
le fichier. Puis par ADO je réalises mes opérations de suppression et
d'ajout.
Cette action est irreversible, confirmez la suppression du commentaire ?
Signaler le commentaire
Veuillez sélectionner un problème
Nudité
Violence
Harcèlement
Fraude
Vente illégale
Discours haineux
Terrorisme
Autre
Jean-Marc
"Christian" a écrit dans le message de news:41948fca$0$21710$
Bonjour,
Je dois importer les données d'un fichier texte dans une table de base de données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou
40
000 fiches (je teste à 100 000).
H1: Je récupère les id du fichier un par un (en boucle) puis supprime la fiche dans la BD. Enfin j'insère une par une les fiches contenues dans le
fichier
vers la BD.
Bien mais trop long en traitement.
H2: J'imagine de créer un recordset déconnecté dans lequel j'insère les
données.
Ensuite à partir de celui-ci je supprime les fiches (requête DELETE matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation. Pourtant ce serait la solution.
H3: Je crée une table dans la BD, j'insère une par une les fiches contenues
dans
le fichier. Puis par ADO je réalises mes opérations de suppression et d'ajout.
C'est la moins pire avec la H2.
Hello,
H1: trop long H2: bof. H3: simple, sans risque, pas de difficutés de programmation performances surment accpetables. Hint: Travailler en transactions avec un Commit tous les 100 ou 1000 records, par exemple.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"Christian" <christgh@nepasutiliser.com> a écrit dans le message de
news:41948fca$0$21710$79c14f64@nan-newsreader-07.noos.net...
Bonjour,
Je dois importer les données d'un fichier texte dans une table de base de
données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en
avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou
40
000 fiches (je teste à 100 000).
H1:
Je récupère les id du fichier un par un (en boucle) puis supprime la fiche
dans la BD. Enfin j'insère une par une les fiches contenues dans le
fichier
vers la BD.
Bien mais trop long en traitement.
H2:
J'imagine de créer un recordset déconnecté dans lequel j'insère les
données.
Ensuite à partir de celui-ci je supprime les fiches (requête DELETE
matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon
j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation.
Pourtant ce serait la solution.
H3:
Je crée une table dans la BD, j'insère une par une les fiches contenues
dans
le fichier. Puis par ADO je réalises mes opérations de suppression et
d'ajout.
C'est la moins pire avec la H2.
Hello,
H1: trop long
H2: bof.
H3: simple, sans risque, pas de difficutés de programmation
performances surment accpetables.
Hint: Travailler en transactions avec un Commit tous les
100 ou 1000 records, par exemple.
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Christian" a écrit dans le message de news:41948fca$0$21710$
Bonjour,
Je dois importer les données d'un fichier texte dans une table de base de données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou
40
000 fiches (je teste à 100 000).
H1: Je récupère les id du fichier un par un (en boucle) puis supprime la fiche dans la BD. Enfin j'insère une par une les fiches contenues dans le
fichier
vers la BD.
Bien mais trop long en traitement.
H2: J'imagine de créer un recordset déconnecté dans lequel j'insère les
données.
Ensuite à partir de celui-ci je supprime les fiches (requête DELETE matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation. Pourtant ce serait la solution.
H3: Je crée une table dans la BD, j'insère une par une les fiches contenues
dans
le fichier. Puis par ADO je réalises mes opérations de suppression et d'ajout.
C'est la moins pire avec la H2.
Hello,
H1: trop long H2: bof. H3: simple, sans risque, pas de difficutés de programmation performances surment accpetables. Hint: Travailler en transactions avec un Commit tous les 100 ou 1000 records, par exemple.
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Quasimodo
Christian wrote on 11/12/2004 :
Bonjour,
Je dois importer les données d'un fichier texte dans une table de base de données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou 40 000 fiches (je teste à 100 000).
H1: Je récupère les id du fichier un par un (en boucle) puis supprime la fiche dans la BD. Enfin j'insère une par une les fiches contenues dans le fichier vers la BD.
Bien mais trop long en traitement.
H2: J'imagine de créer un recordset déconnecté dans lequel j'insère les données. Ensuite à partir de celui-ci je supprime les fiches (requête DELETE matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation. Pourtant ce serait la solution.
H3: Je crée une table dans la BD, j'insère une par une les fiches contenues dans le fichier. Puis par ADO je réalises mes opérations de suppression et d'ajout.
C'est la moins pire avec la H2.
Christian.
re, je pense que si vous utilisez la solution h1 sur base d'un recordset ado ouvert sur un fichier text, cela vous permet d'éviter la perte de temps de création de la table dans la base de données (h3) qui n'est pas n'égligeable, ainsi que les temps de crétion des records pour la solution h2 et h3. Ensuite, si votre fichier text n'est pas trié avec la même clef d'index, ce n'est pas grave, puisque les opération d'accès direct se font sur la db. Donc ouvrez le recordset de la db avec un index, pour avoir l'accès direct par rapport à la clef du fichier text. Evitéz d'avoir d'autre personne en utilisation de la db au même moment, pour ne pas surcharger la db avec une gestion de locking, ... Une autre idée serait d'enlever toute relation de cette table vers d'autre table (via adox), pour enlever une surcharge de gestion à la db, bon cela reste a voir, je ne sais pas si c'est une bonne ou mauvaise idéee, je lance l'idée. Aussi, je pense que l'utilisation de transaction permet une sécuritée accrue non négligeable mais cela au dépend d'un ralentissement des opérations. Pour terminer, une réflection me vien à l'idée, est il mieux, pour un delete de faire son ajout correspondant ou n'est il pas mieux de faire l'ensemble des delete et ensuite des insert, cela dépend fortement de comment fonctionne MS Access?
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
Christian wrote on 11/12/2004 :
Bonjour,
Je dois importer les données d'un fichier texte dans une table de base de
données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en
avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou 40
000 fiches (je teste à 100 000).
H1:
Je récupère les id du fichier un par un (en boucle) puis supprime la fiche
dans la BD. Enfin j'insère une par une les fiches contenues dans le fichier
vers la BD.
Bien mais trop long en traitement.
H2:
J'imagine de créer un recordset déconnecté dans lequel j'insère les données.
Ensuite à partir de celui-ci je supprime les fiches (requête DELETE
matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon
j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation.
Pourtant ce serait la solution.
H3:
Je crée une table dans la BD, j'insère une par une les fiches contenues dans
le fichier. Puis par ADO je réalises mes opérations de suppression et
d'ajout.
C'est la moins pire avec la H2.
Christian.
re,
je pense que si vous utilisez la solution h1 sur base d'un recordset
ado ouvert sur un fichier text, cela vous permet d'éviter la perte de
temps de création de la table dans la base de données (h3) qui n'est
pas n'égligeable, ainsi que les temps de crétion des records pour la
solution h2 et h3. Ensuite, si votre fichier text n'est pas trié avec
la même clef d'index, ce n'est pas grave, puisque les opération d'accès
direct se font sur la db. Donc ouvrez le recordset de la db avec un
index, pour avoir l'accès direct par rapport à la clef du fichier text.
Evitéz d'avoir d'autre personne en utilisation de la db au même moment,
pour ne pas surcharger la db avec une gestion de locking, ... Une autre
idée serait d'enlever toute relation de cette table vers d'autre table
(via adox), pour enlever une surcharge de gestion à la db, bon cela
reste a voir, je ne sais pas si c'est une bonne ou mauvaise idéee, je
lance l'idée. Aussi, je pense que l'utilisation de transaction permet
une sécuritée accrue non négligeable mais cela au dépend d'un
ralentissement des opérations. Pour terminer, une réflection me vien à
l'idée, est il mieux, pour un delete de faire son ajout correspondant
ou n'est il pas mieux de faire l'ensemble des delete et ensuite des
insert, cela dépend fortement de comment fonctionne MS Access?
@+Quaz
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Je dois importer les données d'un fichier texte dans une table de base de données (sous Access) pour remplacer les fiches existantes.
J'hésite sur la façon de procéder. Voici les trois hypothèses. Si vous en avez d'autres n'hésitez pas à me le dire. Il s'agit normalement de 30 ou 40 000 fiches (je teste à 100 000).
H1: Je récupère les id du fichier un par un (en boucle) puis supprime la fiche dans la BD. Enfin j'insère une par une les fiches contenues dans le fichier vers la BD.
Bien mais trop long en traitement.
H2: J'imagine de créer un recordset déconnecté dans lequel j'insère les données. Ensuite à partir de celui-ci je supprime les fiches (requête DELETE matable.Id WHERE matable.Id = Recordsetdeconnecte.ID) et de la même façon j'insère les fiches.
Je ne sais si cela fonctionne, problème de mémoire ou même de réalisation. Pourtant ce serait la solution.
H3: Je crée une table dans la BD, j'insère une par une les fiches contenues dans le fichier. Puis par ADO je réalises mes opérations de suppression et d'ajout.
C'est la moins pire avec la H2.
Christian.
re, je pense que si vous utilisez la solution h1 sur base d'un recordset ado ouvert sur un fichier text, cela vous permet d'éviter la perte de temps de création de la table dans la base de données (h3) qui n'est pas n'égligeable, ainsi que les temps de crétion des records pour la solution h2 et h3. Ensuite, si votre fichier text n'est pas trié avec la même clef d'index, ce n'est pas grave, puisque les opération d'accès direct se font sur la db. Donc ouvrez le recordset de la db avec un index, pour avoir l'accès direct par rapport à la clef du fichier text. Evitéz d'avoir d'autre personne en utilisation de la db au même moment, pour ne pas surcharger la db avec une gestion de locking, ... Une autre idée serait d'enlever toute relation de cette table vers d'autre table (via adox), pour enlever une surcharge de gestion à la db, bon cela reste a voir, je ne sais pas si c'est une bonne ou mauvaise idéee, je lance l'idée. Aussi, je pense que l'utilisation de transaction permet une sécuritée accrue non négligeable mais cela au dépend d'un ralentissement des opérations. Pour terminer, une réflection me vien à l'idée, est il mieux, pour un delete de faire son ajout correspondant ou n'est il pas mieux de faire l'ensemble des delete et ensuite des insert, cela dépend fortement de comment fonctionne MS Access?
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
YannX
Bnjr,
Je rejoins cette preoccupation pour mon pb. Dans un traitement de volume, vaut-il mieux gerer une boucle d'enregistrements (Rst.Delete .Rst.Edit Rst.AddNew) ou une action par lots, genre DB.Execute "DELETE ALL WHERE ) suivi des INSERT (hors contraintes d'analyse...) Merci de l'avis éclairé d'experts / praticiens..... @+
"Quasimodo" a écrit dans le message de news:
Christian wrote on 11/12/2004 : > Bonjour,
. Pour terminer, une réflection me vien à
l'idée, est il mieux, pour un delete de faire son ajout correspondant ou n'est il pas mieux de faire l'ensemble des delete et ensuite des insert, cela dépend fortement de comment fonctionne MS Access?
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
Bnjr,
Je rejoins cette preoccupation pour mon pb.
Dans un traitement de volume,
vaut-il mieux gerer une boucle d'enregistrements
(Rst.Delete .Rst.Edit Rst.AddNew)
ou une action par lots, genre DB.Execute "DELETE ALL WHERE )
suivi des INSERT (hors contraintes d'analyse...)
Merci de l'avis éclairé d'experts / praticiens.....
@+
"Quasimodo" <wild_riki.@yahoo.fr> a écrit dans le message de
news:mn.65517d4bd278a24b.18602@yahoo.fr...
Christian wrote on 11/12/2004 :
> Bonjour,
. Pour terminer, une réflection me vien à
l'idée, est il mieux, pour un delete de faire son ajout correspondant
ou n'est il pas mieux de faire l'ensemble des delete et ensuite des
insert, cela dépend fortement de comment fonctionne MS Access?
@+Quaz
--
This is an automatic signature of MesNews.
Site : http://mesnews.no-ip.com
Je rejoins cette preoccupation pour mon pb. Dans un traitement de volume, vaut-il mieux gerer une boucle d'enregistrements (Rst.Delete .Rst.Edit Rst.AddNew) ou une action par lots, genre DB.Execute "DELETE ALL WHERE ) suivi des INSERT (hors contraintes d'analyse...) Merci de l'avis éclairé d'experts / praticiens..... @+
"Quasimodo" a écrit dans le message de news:
Christian wrote on 11/12/2004 : > Bonjour,
. Pour terminer, une réflection me vien à
l'idée, est il mieux, pour un delete de faire son ajout correspondant ou n'est il pas mieux de faire l'ensemble des delete et ensuite des insert, cela dépend fortement de comment fonctionne MS Access?
@+Quaz
-- This is an automatic signature of MesNews. Site : http://mesnews.no-ip.com
Jean-Marc
"YannX" a écrit dans le message de news:
Bnjr,
Je rejoins cette preoccupation pour mon pb. Dans un traitement de volume, vaut-il mieux gerer une boucle d'enregistrements (Rst.Delete .Rst.Edit Rst.AddNew) ou une action par lots, genre DB.Execute "DELETE ALL WHERE ) suivi des INSERT (hors contraintes d'analyse...) Merci de l'avis éclairé d'experts / praticiens..... @+
Le traitement par lots est dans tous les cas la meilleure solution, et de très loin. En particulier si ta table contient des indexes. Rien que pour les delete, sur une base de 60.000 records, chaque record = 5 champs texte + un ID autonumber, tous les champs indexés):
- delete en séquence (rs.delete) : +/- 25 secondes - SQL (DELETE FROM TABLE1) et db.execute : +/- 6 secondes
Pour les insertions, c'est très variable. Selon le nombre et la nature des indexes, le temps d'insertion peut varier dans des proportions de 1 à 5 (ou plus). Il semble quand même que dans tous les cas, il est préférable de faire tout ça en SQL. Il faut être conscient aussi que Acess montre quand même ses limites sur des bases ou il y a plus que quelques centaines de milliers de records: ça continue à marcher, mais ça rame.
<HS> Bien sur, faut pas en faire toute une histoire. Un traîtement qui ne doit se faire qu'à une fréquence peu élevée ne doit pas nécessairement être hyper rapide: Ce n'est pas tous les jours, sauf en phase de tests qu'on doit insérer des centaines de milliers de records dans une DB. Et si c'est le cas, on ne le fait pas en Access... </HS>
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
"YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de
news:eFUcn3VyEHA.260@TK2MSFTNGP10.phx.gbl...
Bnjr,
Je rejoins cette preoccupation pour mon pb.
Dans un traitement de volume,
vaut-il mieux gerer une boucle d'enregistrements
(Rst.Delete .Rst.Edit Rst.AddNew)
ou une action par lots, genre DB.Execute "DELETE ALL WHERE )
suivi des INSERT (hors contraintes d'analyse...)
Merci de l'avis éclairé d'experts / praticiens.....
@+
Le traitement par lots est dans tous les cas la meilleure solution, et
de très loin. En particulier si ta table contient des indexes. Rien que
pour les delete, sur une base de 60.000 records, chaque record = 5
champs texte + un ID autonumber, tous les champs indexés):
- delete en séquence (rs.delete) : +/- 25 secondes
- SQL (DELETE FROM TABLE1) et db.execute : +/- 6 secondes
Pour les insertions, c'est très variable. Selon le nombre et la nature
des indexes, le temps d'insertion peut varier dans des proportions de 1
à 5 (ou plus). Il semble quand même que dans tous les cas, il est
préférable de faire tout ça en SQL. Il faut être conscient aussi que
Acess montre quand même ses limites sur des bases ou il y a plus que
quelques centaines de milliers de records: ça continue à marcher, mais
ça rame.
<HS>
Bien sur, faut pas en faire toute une histoire. Un traîtement qui ne
doit se faire qu'à une fréquence peu élevée ne doit pas nécessairement
être hyper rapide: Ce n'est pas tous les jours, sauf en phase de tests
qu'on doit insérer des centaines de milliers de records dans une DB. Et
si c'est le cas, on ne le fait pas en Access...
</HS>
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
Je rejoins cette preoccupation pour mon pb. Dans un traitement de volume, vaut-il mieux gerer une boucle d'enregistrements (Rst.Delete .Rst.Edit Rst.AddNew) ou une action par lots, genre DB.Execute "DELETE ALL WHERE ) suivi des INSERT (hors contraintes d'analyse...) Merci de l'avis éclairé d'experts / praticiens..... @+
Le traitement par lots est dans tous les cas la meilleure solution, et de très loin. En particulier si ta table contient des indexes. Rien que pour les delete, sur une base de 60.000 records, chaque record = 5 champs texte + un ID autonumber, tous les champs indexés):
- delete en séquence (rs.delete) : +/- 25 secondes - SQL (DELETE FROM TABLE1) et db.execute : +/- 6 secondes
Pour les insertions, c'est très variable. Selon le nombre et la nature des indexes, le temps d'insertion peut varier dans des proportions de 1 à 5 (ou plus). Il semble quand même que dans tous les cas, il est préférable de faire tout ça en SQL. Il faut être conscient aussi que Acess montre quand même ses limites sur des bases ou il y a plus que quelques centaines de milliers de records: ça continue à marcher, mais ça rame.
<HS> Bien sur, faut pas en faire toute une histoire. Un traîtement qui ne doit se faire qu'à une fréquence peu élevée ne doit pas nécessairement être hyper rapide: Ce n'est pas tous les jours, sauf en phase de tests qu'on doit insérer des centaines de milliers de records dans une DB. Et si c'est le cas, on ne le fait pas en Access... </HS>
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Christian
Merci beaucoup pour tous vos éclaircissements.
Christian.
"Jean-Marc" a écrit dans le message de news: 4195fb82$0$28099$
"YannX" a écrit dans le message de news: > Bnjr, > > > Je rejoins cette preoccupation pour mon pb. > Dans un traitement de volume, > vaut-il mieux gerer une boucle d'enregistrements > (Rst.Delete .Rst.Edit Rst.AddNew) > ou une action par lots, genre DB.Execute "DELETE ALL WHERE ) > suivi des INSERT (hors contraintes d'analyse...) > Merci de l'avis éclairé d'experts / praticiens..... > @+
Le traitement par lots est dans tous les cas la meilleure solution, et de très loin. En particulier si ta table contient des indexes. Rien que pour les delete, sur une base de 60.000 records, chaque record = 5 champs texte + un ID autonumber, tous les champs indexés):
- delete en séquence (rs.delete) : +/- 25 secondes - SQL (DELETE FROM TABLE1) et db.execute : +/- 6 secondes
Pour les insertions, c'est très variable. Selon le nombre et la nature des indexes, le temps d'insertion peut varier dans des proportions de 1 à 5 (ou plus). Il semble quand même que dans tous les cas, il est préférable de faire tout ça en SQL. Il faut être conscient aussi que Acess montre quand même ses limites sur des bases ou il y a plus que quelques centaines de milliers de records: ça continue à marcher, mais ça rame.
<HS> Bien sur, faut pas en faire toute une histoire. Un traîtement qui ne doit se faire qu'à une fréquence peu élevée ne doit pas nécessairement être hyper rapide: Ce n'est pas tous les jours, sauf en phase de tests qu'on doit insérer des centaines de milliers de records dans une DB. Et si c'est le cas, on ne le fait pas en Access... </HS>
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
Merci beaucoup pour tous vos éclaircissements.
Christian.
"Jean-Marc" <nospam_jean_marc_n2@yahoo.fr> a écrit dans le message de news:
4195fb82$0$28099$ba620e4c@news.skynet.be...
"YannX" <ydx_nospam@yahoo.fr> a écrit dans le message de
news:eFUcn3VyEHA.260@TK2MSFTNGP10.phx.gbl...
> Bnjr,
>
>
> Je rejoins cette preoccupation pour mon pb.
> Dans un traitement de volume,
> vaut-il mieux gerer une boucle d'enregistrements
> (Rst.Delete .Rst.Edit Rst.AddNew)
> ou une action par lots, genre DB.Execute "DELETE ALL WHERE )
> suivi des INSERT (hors contraintes d'analyse...)
> Merci de l'avis éclairé d'experts / praticiens.....
> @+
Le traitement par lots est dans tous les cas la meilleure solution, et
de très loin. En particulier si ta table contient des indexes. Rien que
pour les delete, sur une base de 60.000 records, chaque record = 5
champs texte + un ID autonumber, tous les champs indexés):
- delete en séquence (rs.delete) : +/- 25 secondes
- SQL (DELETE FROM TABLE1) et db.execute : +/- 6 secondes
Pour les insertions, c'est très variable. Selon le nombre et la nature
des indexes, le temps d'insertion peut varier dans des proportions de 1
à 5 (ou plus). Il semble quand même que dans tous les cas, il est
préférable de faire tout ça en SQL. Il faut être conscient aussi que
Acess montre quand même ses limites sur des bases ou il y a plus que
quelques centaines de milliers de records: ça continue à marcher, mais
ça rame.
<HS>
Bien sur, faut pas en faire toute une histoire. Un traîtement qui ne
doit se faire qu'à une fréquence peu élevée ne doit pas nécessairement
être hyper rapide: Ce n'est pas tous les jours, sauf en phase de tests
qu'on doit insérer des centaines de milliers de records dans une DB. Et
si c'est le cas, on ne le fait pas en Access...
</HS>
--
Jean-marc
"There are only 10 kind of people
those who understand binary and those who don't."
"Jean-Marc" a écrit dans le message de news: 4195fb82$0$28099$
"YannX" a écrit dans le message de news: > Bnjr, > > > Je rejoins cette preoccupation pour mon pb. > Dans un traitement de volume, > vaut-il mieux gerer une boucle d'enregistrements > (Rst.Delete .Rst.Edit Rst.AddNew) > ou une action par lots, genre DB.Execute "DELETE ALL WHERE ) > suivi des INSERT (hors contraintes d'analyse...) > Merci de l'avis éclairé d'experts / praticiens..... > @+
Le traitement par lots est dans tous les cas la meilleure solution, et de très loin. En particulier si ta table contient des indexes. Rien que pour les delete, sur une base de 60.000 records, chaque record = 5 champs texte + un ID autonumber, tous les champs indexés):
- delete en séquence (rs.delete) : +/- 25 secondes - SQL (DELETE FROM TABLE1) et db.execute : +/- 6 secondes
Pour les insertions, c'est très variable. Selon le nombre et la nature des indexes, le temps d'insertion peut varier dans des proportions de 1 à 5 (ou plus). Il semble quand même que dans tous les cas, il est préférable de faire tout ça en SQL. Il faut être conscient aussi que Acess montre quand même ses limites sur des bases ou il y a plus que quelques centaines de milliers de records: ça continue à marcher, mais ça rame.
<HS> Bien sur, faut pas en faire toute une histoire. Un traîtement qui ne doit se faire qu'à une fréquence peu élevée ne doit pas nécessairement être hyper rapide: Ce n'est pas tous les jours, sauf en phase de tests qu'on doit insérer des centaines de milliers de records dans une DB. Et si c'est le cas, on ne le fait pas en Access... </HS>
-- Jean-marc "There are only 10 kind of people those who understand binary and those who don't."
