Hello,
 
J'ai souvent besoin de travailler avec des tableaux de plus de 30k éléments (le plus souvent des noms de fichiers donc le contenu n'est pas si lourd que ça), mais Excel se casse systématiquement la gueule un peu après avoir dépassé les 30k.  
 
Après avoir recherché un peu sur le net, c'est quelque chose d'apparemment connu, la taille d'un tableau max serait limitée par la mémoire disponible. Sauf que si je crée un tableau qui va contenir plein de tableaux de 30k éléments, pas de problème (avec Excel qui commence à dépasser le Go de RAM utilisée).  
 
J'ai donc un moyen de contourner cette limitation en scindant mon tableau en sous-tableau, mais ça me semble un peu être du bricolage. Pas moyen de créer un tableau de 200 000 lignes si j'en ai envie/besoin ?
 
'ci

Ca dépend des versions d'Excel. Les limites sont repoussées un peu plus loin de temps à autres. Il me semble que la dernière version permet d'aller au-delà de 30K.
 
En attendant les versions prochaines, le bricolage est une solution qui est préférable à une absence de solution.

Salut, qqs infos sur la chose
http://support.microsoft.com/defau [...] -us;177991
http://www.decisionmodels.com/memlimitsc.htm
http://thedailyreviewer.com/office [...] -114611224

Ouais c'est ce que j'avais trouvé

Langage en carton vba quand même , va falloir que je me mette à autre chose un jour pour manipuler des Excel...

Bof, ça tourne plutot bien pour ce que les gens en font.
 
Si déjà vous arretiez de vous en servir comme base de donnée, alors que ça n'en est pas une; il y aura un progrès
(et sans parler de programmer proprement)
 
 
Décris voir le besoin que t'as d'avoir des tableau de 30k éléments en mémoire ?
(30k noms de fichiers ? oO)

M'en sers pas comme base de données non, mais c'est un peu le seul support qu'on a qu'on puisse facilement utiliser pour ce qu'on en fait
Excel est pas loin de proposer exactement ce dont on a besoin et est manipulable sans formation supplémentaire. Après y'a des tâches qui peuvent s'automatiser et c'est là que j'interviens quand j'ai le temps, mais utiliser une vraie base de donnée, j'aurais énormément de boulot à faire pour recréer toutes les fonctions que propose Excel, et j'ai pas forcément le temps/les moyens etc. Donc Excel restera notre support, comme il l'est dans la plupart des boites qui font le même taff que nous

Sur le volume, 30k, y'a pire, ça peut encore se multiplier par 10

Exemple : j'ai d'un côté un fichier Excel de 5 à 10 000 lignes qui contient des noms de fichiers, un répertoire de destination au sein d'une arborescence et une colonne de Feedback. De l'autre, j'ai un dossier avec une arbo inconnue avec deux ensembles de 200 000 fichiers (chaque fichier est présent en deux versions). Pour chaque fichier de l'Excel, il faut que je trouve si les deux versions existent, si c'est le cas, je renseigne un feedback positif et je les copie dans l'arborescence indiquée. Si l'un des deux fichiers n'existe pas (ou les deux), je donne un feedback différent dans l'Excel...

C'est juste un exemple (choisi parmi les plus gros pour l'exemple), mais gérer des relations classeur(s) Excel / milliers de fichier c'est très commun dans ce que je fais.

Quant à programmer correctement, ça fait déjà 7 ans que j'ai fini mon DUT info (pfiew ça passe vite), j'ai changé de branche immédiatement, donc j'ai des bases mais ça s'oublie. Alors tout n'est pas parfaitement programmé (d'autant plus que j'ai pas mal de trucs qui sont fait à la volée en fonction d'un besoin précis dans l'urgence), mais c'est pas non plus complètement fait n'importe comment

Ok, effectivement
 
je reprend ton besoin si j'ai bien compris :
 
Dans Excel, t'as X nom de fichier
pour chaque nom de fichier tu va vérifier s'il existe dans les deux arborescences
selon les cas, tu remplis ton champs de feedback
 
(j'ai juste ?)
 
Question :
tes deux arborescences, t'y accède comment ?
 
 

C'est à peu près ça oui Y'a des opérations intermédiaires (copie des fichiers dans un répertoire précis indiqué dans Excel par exemple), et il peut y avoir moultitudes de fichiers Excel (cas extrême récent, plus de 1500 Excel ^^), mais en très résumé c'est ça
 
Je suis pas sûr de comprendre la question Tentative de réponse donc  
Mon point d'entrée c'est un dossier, avec un sous répertoire pour chaque lot de fichiers, et après c'est une grosse arbo avec pleins de sous-dossiers (que je connais pas à l'avance bien sûr, ça serait trop facile )

en fait dans la logique que je comprend pas ou est ce que tu as besoin de gros tableau de 10k éléments ?
 
d'ou ma question, l'arborescence, tu ne fait que la parcourir sans la stocker ?

Question de rapidité en fait. Si pour chaque fichier je dois me retaper toute l'arbo pour trouver s'il existe ou pas, ça prend trois plombes et ça pourris le réseau pour les autres utilisateurs.  
 
Alors qu'une fois stocké, j'ai juste à parcourir le tableau une fois p)ar fichier, et ça va beaucoup plus vite

HAAAA,
parceque tu ne sais pas ou peut être le fichier dans l'arborescence donc

Ben non, spa drôle sinon

t'as testé avec FileSystemeObject de faire un "FileExist" dans chaque dossier, et sous dossier ?
 
c'est si long que ça ?
 
 

J'utilise ça dans d'autres situations quand je sais où sont les fichiers, et c'est relativement long oui, surtout que les fichiers ne sont pas forcément en local sur mon poste

J'ai pas quantifié ça, mais je pense que le chargement de tous les noms de fichiers dans un tableau Vs le Fileexist est beaucoup plus long...

Bah ça dépent du nombre de sous dossiers, pas du nombre de fichiers
et tu t'arrete dès que t'as trouvé
Il n'y a que dans les cas ou c'est absent que tu te tape autant de fileexist que de sous dossiers...
 
a toi de voir

Ouep, vais faire un test quand même histoire de comparer la rapidité d'exécution (mais demain, hein faut pas pousser, vais rentrer chez moi )

Merci pour la piste

Et je me demande si la rapidité d'un FileExist est pas lié au nombre de fichiers dans un dossier tiens

Me rapelle plus les cours de système de fichier....
mais normalement, si c'est indexé correctement, ça ne devrait pas
c'est comme chercher un mot qui n'existe pas dans le dictionnaire
ça ne dépend pas du nombre de mot de ce dictionnaire.
 
 

Ça semblerait logique oui
 
Vais test tout ça si j'ai un peu de temps