Bonjour à tous!!
 
J'ai un petit soucis, j'ai besoin de récupérer des données de plusieurs fichier CSV dans ma base de données access. Le truc c'est que ces fichiers sont très lours, don 1 qui fais exctement 173Mo (je sais mm pas il comporte de ligne, mais en tout cas Excel ne peut pas l'ouvrir!)
 Donc le problème c'est que quand je lance mon appli pour lire le fichier elle plante! (enfin jje la lance le matin à 10h, à 17h ça n'a toujours pas finis de tourner, donc je suppose qu'elle à planter, non??
Donc je me demandais si c'étais possible de découper le fichiercsv, ou de lme lire en partie et de reprendre la lecture une heure plustard, enfin de faire en sorte que ça ne plante pas!
voici mon code (mon code fonctionne sur des fichier de 5Mo, mais je pense qu'il est pas assez performant pour  175Mo) :
 
--------------------------------------------------------------------------------
 

 
--------------------------------------------------------------------------------
Merci beaucoup à tous!!

Pour savoir, s'il y a un plantage ou juste un traitement très long, il faudrait avoir des traces.
 
De toutes façons, le VBA est très lent, et de plus, la méthode employée pour lire ce fichier n'est peut-être pas la plus performante. Peut-être que le code old-school suivant serait plus performant :

Tu peux normalement mettre le débuggeur en pause avec CTRL+PAUSE, tu cliques sur Débugger et en regardant le contenu des variables tu peux savoir où il en est. Et tu peux le remettre en marche après.

Merci olivthill, je vais tester ça tout de suite!!
Donc apparement le fait que mon fichier soit gros ne devrais pas poser de problème???
Je testerai toutes les heures le debugger pour voir si tout roule!
merci à vous 2 pour vos réponses!!

Pour infos, En VBA l'écriture d'un fichier de 176MO prend 9 secondes, et sa lecture avec le split prend 25 secondes.

Je n'ai pa pu tester avec le code indiqué car "Set myFSO = CreateObject("Scripting.FileSystemObject" ), c'est du VBS et non du VBA Access, ou bien peut-être du VBA d'une nouvelle version ou avec une configuration particulière.

J'ai aussi testé en VBS, et cela prend 49 secondes pour mon fichier de 176MO. Donc le problème ne doit pas venir de la lecture.

Merci pour tes réponses!!!
Bah je code en VBA donc je suis plus interressée par le code en VBA. Bah mon big fichier de 176Mo contient une liste d'intervenants avec des informations. je lis chaque ligne, et sur chaque ligne je récupère des données, je teste si ces données, sont déjà présente dans une de mes table (donc une requete sql à éxécuté) si c'sst pas le ca jinsere la ligne (2e requete sql) sinon j'insere la ligne en incrémentant le nombre (intervenant info2, intervenant info3 etc...) donc j'execute au moins de requete sql par ligne. a ton avis ça vient de la?
car quand mm plus de 6h d'execution c'est beaucoup!
je vais essayer de tester avec ton code.

Pour ma part, j'importerais toutes les données d'un seul coup dans une table temporaire, et ensuite je ferais les traitements sql nécessaires. Suivant la façon dont tu lances ta requête et l'emplacement de ta base, ça peut être effectivement très long d'exécuter ligne après ligne une requête.

exactement ce que j'allais dire : un import est quand même assez classique dans ce cas (mais pas systématique)

bonjour à tous!!!
 
bon suite à mon problème de temps avec mon fameux fichier csv de 170mo, j'ai eu (la bonne) idée d'exporter directement mon fichier dans une autre base de données access, il semblerai que les accès à une autre base de données access soit plus rapide que els accès à un fichier csv (je me trompe,)
en plus ce qui est pratique, c'est que je peux chercher plus précisément ce que je veux, pour insérer les informations dans ma 1e base.
 
donc petit soucis, la table de ma 2e page (celle qui contient le fichier de 170mo) fais 1 800 000 lignes comme le fichier, et en fait pour récupérer els infos de cette base dans ma base 1, je fais une requete où je demande de sélectionné certaine colonne de cette selon certain critère, et afin de récupérer els données ligne par ligne, j'ai mis un compteur (c'est un integer) appellé ligne.
 
Le soucis c'est que a environ 35000 lignes (le compteur = 35000) le compteur déclenche une erreur de type 6 "Dépassement de capacité"!
Comment y remédier, une idée? merci beaucoup!!!
 
j'utilise mon compteur comme ceci :
 

 
et c'est sur cette ligne que access se stoppe.

Non. Une base de données est forcément constituée d'un ou de plusieurs fichiers. Donc, ça ne peut pas être plus rapide (il pourrait juste y avoir une prélecture, mais cela ne ferait que déplacer le problème). Mais de toutes manières, mes tests ont montré que la lecture du fichier entier prend moins d'une minute sur mon vieux PC. Donc le problème du traiement qui dure plusieurs heures n'a aucun rapport avec la lecture du fichier. Le problème ce situe dans ce qui se trouve derrière les "actions" pour chaque ligne lue.

bonjour olivthill!
bah je pense que c'est les nombreuses requetes et test qui font font ralentir le traitement. j'ai chronométré hier, ça met 1minutes et 16secondes pour traiter 1 000 lignes. vu que j'en ai 1 800 000 j'ai fais le calsul j'en ai pour 25 ou 30heures je sais plus. donc galere, donc du coup avec ma base de données, je faisdes requetes spécifique comme ça je récupère 100 000 lignes par 100 000 lignes.
 
Enfin si je n'arrive pas à optimiser le temps c'est pas grave, mais parcontre je ne comprend pas l'erreur 6, dépacement de capacité.  
j'ai regardé sur internet le plus grand interger c'est genre 2 milliard et des poussieres, donc j'en suis loin avec mes 35 000.
 
un bout de code peut peut-être te donner une idée?:
 

J'oubliai!! merci beaucoup!!

Ligne as Long fonctionnera bcp mieux
Integer = 32767 max

bonjour 4get9!
 
merci pour l'info je test ça tout de suite!!!
je ne savais pas que c'etait limité à 32000 les integers.

si tu veux tu peux aussi faire une table liée (dans ta base 1 tu créé une table liée à la table de la base 2)
Ainsi tu pourra travailler comme si c'était une table locale.
 
Sinon : tu dois utiliser toutes les lignes ? ou seulement une partie ?

re!
bonne idée de liée les tables, je n'y avais pas pensé....
bah à la base je dois utilisé toutes les lignes, mais c'est carrément trop long, donc jme suis dis autant profiter des requêtes pour faire par paquets de lignes.
 
donc à ton avis si je lie toutes les tables de ma 2e base access, àma 1e, les traitement seront plus rapide?
 
merci!

J'pense que la différence sera sensible question perfs
par contre question code, ça sera bcp plus simple.
 
Sinon question : que fait ton code au juste ?

en gros je récupère chaque ligne de mes fichiers csv, et je les inseres dans ma base de données. en fait elle contient les informations sur tous les intervenants de mon entreprise, donc c'est un gros truc. chaque intervenant à plusieurs informations éparpillées dans plusieurs fichiers.
donc quand je lis une ligne d'un fichier je dois retrouvé cet intervenant dans la base afin d'insérer la ligne correctement dans la table appropriée. je récupère une information typique à l'intervenant qui me sert de clé primaire en fait.
 
donc ce qui fais que dès que je lis une ligne je fais à peu près 3 requêtes, car je dois repérer dans quelle table je dois inséré l'information, si c'est pas un doublons.... donc du coup ça ralenti enormément.
 
pour lié les tables j'utilise simplement l'assistant access? et une fois liée je les traite comme si elle était en locale?
merci.

Hou la... ça me semble bien complexe ton traitement... !
 
Pourquoi as tu besoin de dispatcher tes informations dans plusieurs tables ? Sont-elles hétérogènes au point de devoir créer des tables différentes ?
 
Tu dis que tu dois faire une requête pour savoir à quel intervenant appartient l'information : N'y a t-il pas un moyen de le repérer grace au fichier ? Par exemple son nom de fichier ou son emplacement ?
 
Telle que je vois le truc, je le redis, importe toutes tes infos dans une seule table, quitte ensuite à utiliser les assistants d'access pour la fractionner en plusieurs pour traiter les doublons.
 
Ceci dit, au départ, tu parle d'un fichier de plusieurs milliers de lignes, maintenant, c'est de plusieurs fichiers dont il s'agit.

oui

sinon tu pourrais nous donner un extrait de ton fichier ?
 
ATTENTION à bien retirer tout ce qui concerne la confidentialité (remplace nom/matricule/adresse/code de carte bancaire/... par des trucs bidon)

J'espère pour toi que tu n'a pas créé une table par intervenant, chacune de ces tables ayant les même champs !

Ca ne m'étonne pas que ça rame : à chaque ligne, tu relances le moteur de la base, ce n'est pas très efficace.

Bonjour à tous! et merci de toutes vos réponses!
 
Kapote Nestor:

 
Non je n'ai pas mis un intervenant par table, j'aurai eu plus de 20000 tables!!!!! hi!
j'ai une table intervenant qui contient la totalité des informations générales de l'intervenant (nom, prénom, adresse ....)
 
Kapote Nestor:

 
En fait j'ai une trentaine de fichier csv à inséré dans lma base de donnée, mais seul 1 fichier pèse 170Mo et seulement lui me posait problème s'est pourquoi, je n'ai parlé que de celui là au départ.
 
Je vais essayé d'être plus rpécise sur ce que je fais:
Il y a 20 000 intervenants que je dois inséré dans ma base de données.
C'est intervenants sont découpé par type (10 au total), chaque type est contenu dans un fichier.  
prenons le 1e fichier, il va contenir les Détails généraux des intervenants de type A.
Il y a 3 sorte de fichier par type, les Détails généraux, les zones géoographiques (où ils interviennent), les détails des zones géographiques (où ils interviennent), tout ça par type, ça fais 3 (types de fichiers) * 10 types d'intervenant = 30 fichiers .csv
 
Ils ont une appellation spéciale, avec dez chiffres, mais j'ai fais une petite appli qui s'est les reconnaitre.
 
donc pour avoir l'intégralité de ces données, j'ai crée plusieurs table intervenants, convention... zone_Géo_Matrque1, zone_géo_Marque2, zone_géo_Marque3 etc. (j'ai du inséré les zones géographique par marque car sinon il y aurait eu trop de ligne dans une table)
 
C'est pourquoi je fais autant de test avant de lire une ligne, car un intervenant peut avoir plusieurs conventions, donc si il a 2 conventions, on observe 2 lignes distinctes dans le fichiers .csv, il faut que je fasse des test pour insérer ses informations par la suite dans ma base de données.
 
voilà.
 
4get9 :

 
je ne préfère pas mais si ce que je viens d'expliqué plus haut, est encore trop embrouillé je vous transmettrai un exemple de fichier dans ce cas.
 
Donc pour en revenir à la discussion, je pense que les tests que je fais sont nécessaires, et sont la première cause de ralentissement, après vraiment, je ne sais pas comment faire mieux.
 
si vous avez des idées?
merci beaucoup!