Fichier Excel macro de plus en plus lent

Bonsoir nico5310,

Ça me fait très plaisir que tu regardes Access !

Mais attention ! dans Access, il n'y a plus de notions de feuilles de calcul ni de cellules !!!

Donc tu peux reprendre uniquement du code VBA qui en est indépendant, par exemple

si tu as fait une fonction personnalisée qui affiche un résultat sans le mettre dans une

cellule ; le mieux est alors de partir quasiment de 0, mais avec toutes les possibilités

d'une Base de données.


Tu dois d'abord créer les Tables (champs et types) ; ensuite, tu peux saisir tes données

directement dedans ; mais tu peux aussi créer un formulaire (la fiche client) et saisir

tes données à partir du formulaire ; il faut que tu comprennes bien que même ainsi,

les données sont quand même stockées dans les Tables.

Plus tard, il faudra que tu vois les possibilités des Requêtes et des États ; chaque chose

en son temps : tu ne peux pas apprendre Access d'un seul coup, comme par magie !


Quand tu utiliseras des Requêtes, ça te ressortira les données qui t'intéressent, et tu pourras

modifier les données si besoin ; là encore, les données sont toujours dans les Tables : on dit

qu'elles sont sous-jacentes.

Cordialement

Bonjour le fil

@ nico5310

nico5310 a écrit :

Merci pour votre retour, je suis donc en train de me pencher sur Access.

Je pense que tu fais une erreur

Ton fichier actuel, n'est lent que par manque de méthode et de technique.

Le temps que tu vas prendre à te former sur Access, qui n'a absolument pas la même facilité d'accès d'Excel n'en vaut pas la chandelle. De plus Access n'apportera absolument rien à ton application actuelle, sauf à l'alourdir encore.

Je pense que tu as très bien compris que je suis un fervent défenseur d'Excel, néanmoins je ne dénigre absolument pas Access.

Mais j'insiste ! Le temps à investir dans la formation nécessaire à connaître suffisamment Access, et je ne parle pas de sa logique orientée Base de Données Relationnelles qui à mon sens, pour un non-informaticien reste quelque peu absconse, pour reproduire tes tableaux qui sont finalement très simples.

En résumé, j'ai peur que tu te retrouves avec finalement plus de fichiers à traiter que d'onglets actuellement dans ton outil.

Quand je parles de méthode et de technique, je veux dire que certaines fonctions sont très lentes sur Excel, notamment celles qui sont issues de l'enregistreur de macro-commandes, ce qui est très souvent le cas dans ton outil. Je parle ici des Select, Copy et autres Paste... ainsi que les Activate et autres changements intempestifs d'onglets qui ne sont pas nécessaires en programmation...

On parle souvent à tort, de macro-commandes sur Excel. VBA est un vrai langage de programmation, il permet de s'affranchir des limites ou contraintes d'Excel en employant des vraies méthodes de programmation ! La solution à ton problème est là pas dans Access !


Je le répète assez souvent je suis le premier à proposer de structurer sous forme de Base de Données, et les différents intervenants de ce fil le savent très bien.


Mais dans ton cas précis, il ne s'agit pas d'une Base de Données mais de tableaux multiples qui s'alimentent l'un par l'autre. Il n'y a aucun intérêt à structurer cela dans un SGBDR. Je pense au contraire que tu perdrais en confort d'utilisation.

Les données traitées dans ton outil, sont parfaites telles qu'elles sont présentées, alors pourquoi les (ré) écrire avec un logiciel que tu ne connais pas, ou en tout cas moins qu'Excel.

J'ai effectivement récupéré toutes mes feuilles Excel sur le fichier Acces ainsi que les macros. Mais celle-ci ne sont apparemment pas compatibles entre Excel et Acces ( ça serait trop facile ! :/ . J'ai importer mes macros dans les modules mais apparemment la programmation n'est pas la même Donc ça ne m'arrange pas du tout !

En effet, le fait de faire les macros sur Excel m'a apporté un grand confort du fait de ne pas avoir a copier ligne par ligne sur l'onglet voulu, mais d'automatiser le fonctionnement et donc de gagner du temps car je traite environ 80/90 mouvements de ligne par jour.

Mais Excel devient vraiment trop lent. Donc soit je peux simplifier mes macros afin de gagner de la fluidité sur le traitement de mon fichier Excel, soit Access est capable de faire ce que je souhaites (faire des transferts de ligne d'une table a l'autre avec des boutons et des macros) et donc dans ce cas je me pense dessus sérieusement.

Je ne suis pas assez calé dessus, vous êtes plus expert que moi a ce sujet !

Mais celles-ci (les macros) ne sont apparemment pas compatibles entre Excel et Access.

As-tu bien lu mon message précédent ? dhany

Bonjour le fil

@nico5310

nico5310 a écrit :

Mais Excel devient vraiment trop lent. Donc soit je peux simplifier mes macros afin de gagner de la fluidité sur le traitement de mon fichier Excel

Réponse :

NCC 1701 a écrit :

On parle souvent à tort, de macro-commandes sur Excel. VBA est un vrai langage de programmation, il permet de s'affranchir des limites ou contraintes d'Excel en employant des vraies méthodes de programmation ! La solution à ton problème est là pas dans Access !

@dhany + le fil

Pourquoi l'embrouillez vous avec Access... Je ne comprends pas où vous voyez un quelconque besoin de base de données dans ce fichier tout simple... Les 9 (si je ne me trompe pas) tableaux sont tous identiques ! Le vrai problème de nico5310 ce n'est pas la lenteur d'Excel, c'est la lenteur de la méthode employée Access n'apportera rien à cet outil si la même méthode est employée.

Bonjour NCC 1701,

Tu a écrit :

Pourquoi l'embrouillez-vous avec Access...

Loin de moi l'idée de chercher à embrouiller notre ami nico5310 !!! simplement, quand toi tu dis « fais-le avec Excel »,

moi je préfère dire « regarde aussi Access et ses possibilités, puis choisis ce que tu préfères » ; n'a-t-il pas le droit

de garder son libre arbitre ?

En fait, je lui propose de regarder aussi Access dans un cadre plus général, en me disant que si un jour il a besoin

de gérer plusieurs milliers de fiches au lieu de quelques centaines, Access pourra lui être très utile.


Tu a écrit :

Je ne comprends pas où vous voyez un quelconque besoin de base de données dans ce fichier tout simple...

Par rapport au fait qu'il y a seulement quelques centaines de fiches clients, je trouve qu'on peut voir les choses aussi bien

selon Access que selon Excel :

1) Access permet de stocker toutes les données des fiches clients dans des Tables (en utilisant ou non un Formulaire) ;

ensuite, on peut utiliser des Requêtes pour interroger la Base de données et faire ressortir les données qui nous

intéressent parmi toutes les autres ; et on peut aussi créer des États pour faire de belles impressions ; Access est

basé sur les 4 objets en bleu que je viens de décrire (et j'ai bien décrit aussi leur utilité respective) ; ceci est tout

à fait objectif, personne ne peut le nier, et c'est selon les fonctionnalités et possibilités d'Access, pas selon les

aptitudes plus ou moins aisées de l'utilisateur à apprendre et à utiliser ce logiciel ; essayer de faire la même

chose avec Excel ? c'est peut-être possible, mais : « pourquoi réinventer la roue ? »

2) nico5310 peut effectivement utiliser Excel pour gérer toutes ses fiches clients, même sans avoir toutes les possibilités

d'Access décrites au point 1) ; et du fait qu'il y a moins de 1 000 fiches clients, je suis entièrement d'accord avec toi :

à condition de bien organiser les données et de se servir correctement d'Excel (et de son VBA), on peut fort bien

se passer d'Access.

Pour moi, les 2 logiciels sont valables et envisageables ; je ne peux forcer quiconque à utiliser Excel ou Access,

simplement, je laisse le choix à nico5310.


Tu a écrit :

Les 9 tableaux sont tous identiques ! Le vrai problème de nico5310 ce n'est pas la lenteur d'Excel,

c'est la lenteur de la méthode employée

De ce point de vue qui est très juste, je me range de ton côté et je conseille aussi à nico5310 d'utiliser Excel ;

mais c'est quand même à lui de choisir et décider en dernier ressort, avec tous les éléments que j'ai indiqués.

Cordialement

Bonjour le fil

@dhany

Pour étayer mes propos je t'invite à consulter ce fil https://forum.excel-pratique.com/post590361.html#p590361 sur lequel tu est actif... Et tu verras que c'est bien la manière d'utiliser l'outil qui compte et non l'outil lui même !

Certes il y a des outils pour certaines choses et d'autres outils pour d'autres choses.

Comme dirait James007 on n'enfonce pas un clou avec une chaussure mais avec un marteau

Je suis un fervent défenseur d'Excel, certes, mais surtout et aussi de la structuration en Base de Données, et plus encore je suis informaticien de plus de 30 ans d'expérience. Faire du VBA en mode enregistreur de macro-commandes n'est pas de la programmation, c'est de la bidouille. Et en considération de l'époque et de mon expérience je suis de l'école de l'algorithmique, des langages structurés et des programmes pensés, organisés, optimisés...

Les demandeurs de ce forum, ne peuvent tous être informaticien, il utilise Excel parce qu'il est simple à manipuler au premier abord. Un tableau représente quelques chose de naturel dans le cerveau humain. C'est n'est pas le cas d'une Base de Données. Si elle est mal pensée, mal construite sur Excel elle le sera également sur Access.

Un outil informatique, ne doit pas ralentir l'utilisateur ! Il doit lui faciliter la vie ! Il doit optimiser son temps de travail, pas le ralentir ! Il doit être pratique, sinon il sera abandonné !

C'est en tout cas ma vison de la chose, et je pense que dans les ordinateurs ont été inventé pour cela dans les années 50. Nous avons fait énormément de progrès dans les années 60 en matière de performances électronique pure, puis d'autres dans les années 80 en matière de programmation. Depuis rien ou presque n'a changé ! Il y a eu la POO, et les nouveaux langages ! Puis il y a aussi les progrès en matière d'électronique. Mais ce n'est pas parce qu'aujourd'hui nous avons des PC 1000 fois plus rapide (la vitesse actuelle des PCs se compten en GHz, le PC dans les années 80 tournait à 4,77 Mhz) et avec presque 3 000 000 de fois plus de mémoire (en Go aujourd'hui, limité à 640 Ko avant) que cela nous autorise à s'affranchir des méthodes éprouvées !

De plus et entre parenthèses quel est le nom de ce forum ? Ceux qui veulent apprendre Access sauront ce tourner vers la forum approprié !

Tu as écrit qu'une Base de données peut être mal construite : tout à fait d'accord avec toi !

si tel est le cas, ça ne vaudra pas grand chose ! ... et idem si tableur mal construit !

Je pense que tu connais cette expression : « garbage in, garbage out » :

traduction : poubelle en entrée ➯ poubelle en sortie


Tu as écrit : « quel est le nom de ce forum ? » ; va donc pour Excel !

Excel adopté à l'unanimité !!!

Bonjour,

Merci pour vos échanges qui m'apprennent beaucoup sur la vision d'utilisation des outils.

Le problème d'utilisation d'Access est résolu car n'est pas accessible sur mon poste de travail..... je l'ai chez moi mais pas au boulot...

Donc, je suis obligé d'améliorer mon fichier Excel actuel car au final il me sert qu'au boulot

Avez vous des idées ? Car comme expliqué précédemment je suis "novice" en programmation. Je me suis débrouillé comme je pouvais avec mes macros mais la ca dépasse largement mes compétences.

Merci pour votre aide

Bonjour nico5310

Heureux de te revoir parmi nous. Heureux également que tu abandonnes cette idée saugrenue !

@NCC 1701

NCC 1701 a écrit :

Heureux également que tu abandonnes cette idée saugrenue !

Saugrenue ? non ! pourquoi veux-tu donc tellement décider à la place des autres ce qui est mieux pour eux ?

et si nico5310 avait eu Access sur son poste de travail, ça aurait été une solution tout à fait envisageable !!!

Bien sûr, si on suit ton préjugé selon lequel il faut être informaticien pour utiliser Access, ou qu'Access est strictement

réservé aux non-débutants, alors aucune personne « normale » ne devrait apprendre Access et l'utiliser ! c'est plutôt

ça qui est saugrenu et ridicule !

On est ici sur un forum Excel, d'accord ! mais si quelqu'un demande un bifteck dans une boulangerie,

il me semble que c'est tout à fait normal qu'on l'aiguille sur une boucherie, non ?

Mais puisque de toute façon nico5310 doit utiliser Excel, la question ne se pose plus,

et je te laisse le soin de l'aider davantage.

Salut Nico,

Salut l'équipe,

en supprimant toutes les règles de MFC dans toutes tes feuilles et en évitant les copy, le transfert de données est quasi instantané.

Il faudrait l'avis d'un connaisseur en fonctionnement interne d'Excel pour expliquer cela... et si c'est même lié à cette floppée de MFC.

Toujours est-il que je constate une fameuse différence.

Pour avancer, peux-tu faire une copie de ton fichier de travail, en supprimer TOUTES les MFC et tester le code ci-après (à coller dans le module de la feuille 'STOCK') ?

Sub Worksheet_Change copie une ligne dès un changement en [L:L] ATTENTION : valable uniquement pour GIMENEZ, TRANSPORT et SUD !!

Sub Worksheet_SelectionChange te permet (seule possibilité encore - test!!) en cliquant en colonne [A:A] de préparer un transfert groupé vers 'AFFECTATION' : la mention GIMENEZ s'inscrit en [L].

Ensuite, tu sélectionnes plusieurs lignes : quand tu lâches, toutes les lignes sont transférées en une fois.

Bon, je ne m'occupe pas encore des couleurs.

Si ce test te donne satisfaction, question vitesse, on pourra s'occuper de remplacer tes MFC par un code VBA pour récupérer tes couleurs.

Private Sub Worksheet_Change(ByVal Target As Range)
'
Dim iRow As Integer, iRowT As Integer
'
Application.EnableEvents = False
Application.ScreenUpdating = False
'
iRowT = Target.Row
If Not Intersect(Target, Range("L:L")) Is Nothing And Target <> "" Then
    With Worksheets(Switch(UCase(Target) = "GIMENEZ", "AFFECTATION", UCase(Target) = "TRANSPORT", "TRANSPORT", UCase(Target) = "SUD", "VO SUD"))
        iRow = .Range("A" & Rows.Count).End(xlUp).Row + 1
        .Range("A" & iRow & ":L" & iRow).Value = Range("A" & iRowT & ":L" & iRowT).Value
        Rows(iRowT).Delete shift:=xlUp
    End With
End If
'
Application.ScreenUpdating = True
Application.EnableEvents = True
'
End Sub

Private Sub Worksheet_SelectionChange(ByVal Target As Range)
'
Dim sWk As Worksheet
Dim iRow As Integer, iRowT As Integer
'
Application.EnableEvents = False
Application.ScreenUpdating = False
'
If Target.Count > 1 Then
    iRowT = Target.Row
    iRowE = (Target.Rows.Count + iRowT) - 1
    Set sWk = Worksheets("AFFECTATION")
    For x = iRowT To iRowE
        iRow = sWk.Range("A" & Rows.Count).End(xlUp).Row + 1
        Range("L" & x).Value = "GIMENEZ"
        sWk.Range("A" & iRow & ":L" & iRow).Value = Range("A" & x & ":L" & x).Value
    Next
    Range("A" & iRowT & ":L" & iRowE).Delete shift:=xlUp
Else
    iRowT = Target.Row
    Range("L" & iRowT).Value = ""
    '
    If Not Intersect(Target, Range("A:A")) Is Nothing And Target <> "" Then
        Range("L" & iRowT).Value = "GIMENEZ"
    End If
End If
'
Application.ScreenUpdating = True
Application.EnableEvents = True
'
End Sub

A+

Encore plus rapide en utilisant un tableau.

Private Sub Worksheet_SelectionChange(ByVal Target As Range)
'
Dim sWk As Worksheet
Dim tData
Dim iRow As Integer, iRowT As Integer
'
Application.EnableEvents = False
Application.ScreenUpdating = False
'
If Target.Count > 1 Then
    iRowT = Target.Row
    iRowS = Target.Rows.Count
    Range("L" & iRowT & ":L" & (iRowS + iRowT) - 1).Value = "GIMENEZ"
    tData = Range("A" & iRowT & ":L" & (iRowS + iRowT) - 1).Value
    With Worksheets("AFFECTATION")
        iRow = .Range("A" & Rows.Count).End(xlUp).Row + 1
        .Range("A" & iRow).Resize(UBound(tData, 1), UBound(tData, 2)).Value = tData
    End With
    Range("A" & iRowT).Resize(UBound(tData, 1), UBound(tData, 2)).Delete shift:=xlUp
Else
    iRowT = Target.Row
    Range("L" & iRowT).Value = ""
    '
    If Not Intersect(Target, Range("A:A")) Is Nothing And Target <> "" Then
        Range("L" & iRowT).Value = "GIMENEZ"
    End If
End If
'
Application.ScreenUpdating = True
Application.EnableEvents = True
'
End Sub

A tester

Super !! Trop rapide !!

Par contre il y a un petit soucis, le transfert s'effectue aussi si autre chose en noté lors la sélection/laché autre que GIMENEZ TRANSPORT ou SUD (Colonne L). Idem si je sélectionne 2 lignes (cellules) par erreur et que je lâche (exemple je sélectionne L43 + L44 ou F30 + F31, etc...)

C'était un test, Nico!

Pour le côté pratique, puisque tu retrouves ta vitesse d'exécution, il va falloir que tu nous expliques ta façon de fonctionner ou, du moins, la façon dont tu voudrais que le code fonctionne.

Egalement, si tes couleurs sont importantes pour toi (et j'imagine que oui) :

  • faire la liste des mots pour lesquels il faut appliquer une couleur (et quelle couleur), dans quelles colonnes,...;
  • donner les conditions dans lesquelles une ligne se colore (et quelle couleur) ;
  • si c'est nécessaire que ces couleurs émigrent avec leurs données ;

-... et ceci pour chaque feuille si tu veux éviter les MFC (si ce sont bien elles qui ralentissent... J'espère toujours une confirmation, les cracks!).

A te lire.

A+

Je viens de relire un post précédent avec l'explication de ton boulot.

Finalement, tu n'as pas vraiment besoin de couleurs...

le code peut se suffire des indications dans [L]...

A toi de préciser tout ça!

A+

Merci pour ta réactivité !!

Le fonctionnement

STOCK

C'est ma feuille de stock général. Ces sont des véhicules avec des dossiers qui sont en cours de traitement. Je le remplis tous les jours ligne par ligne tout au long de la journée au fur et à mesure des expertises (environ 30 / jours)

Certains véhicules m'appartiennent (Colonne E => DIAC LOC et REPRISE et colonne D CLIENT => CARGO)

D'autres ne sont que de passage et appartiennent à des loueurs (OVERLEASE ainsi que toutes les lignes qui ont une date en colonne F, ALD, ARVAl, etc....)

Concernant les véhicules qui m'appartiennent.

Lors de la saisie du dossier, je note AFFECTATION en colonne L afin de connaitre le nombre de dossier prêts à être donné au chef de vente VO (CVVO).

Lorsque j'ai suffisamment de dossiers, je transferts les dossiers de ces véhicules en créant une liste d'affectation que j'envoie à CVVO.

Pour "sortir" ces véhicules de ma feuille STOCK et créer cette liste, je les transferts dans l'onglet AFFECTATION en changeant le statut du dossier par la colonne L. Pour ce fait, je note GIMENEZ (nom du chef de vente) dans la colonne L au lieu d'AFFECTATION.

Pour aller plus vite, je filtre la colonne L en sélectionnant AFFECTATION et je décoche le reste. Ensuite, je change la première case en GIMENEZ que je duplique sur les autres cases.

Je lance ensuite la MAJ. Les fichiers sont donc transférés (couper/coller) de la feuille STOCK => AFFECTATION. Je copie ensuite la liste que je colle sur un autre fichier (plus léger ) en faisant un classement par ordre alphabétique d'immatriculation) que j'envoie au CVVO.

Une fois son retour, je copie/colle ces affectations (VOM, VO SUD, VO NORD, VOM etc....) dans la colonne M de la feuille AFFECTATION.

J'active la MAJ qui va dispatcher les lignes sur le bonne feuille (SUD => VOSUD, VOM => VOM, etc...) Je n'ai plus qu'a remplir les dates manuellement sur chaque feuille de destination.

Concernant la feuille VO SUD => IL me faut une possibilité d'effectuer un transfert vers la feuille VOM car il est possible qu'il y ait un changement d'affectation plusieurs jours après le choix initiale.

Concernant la feuille VOM => Cette feuille récapitule la liste des véhicules destinés aux enchères. Les véhicules seront donc enlevés de mon stock dans les jours prochains par des transporteurs. Une fois récupéré par le transporteur, j'indique la date de récupération dans la colonne Q et je fais une MAJ. Le véhicule est donc transféré de VOM => TRANSPORT. Je n'ai plus qu'a indiquer le nom de la compagnie de transport.

La feuille SOCCO fonctionne comme la feuille VOM ( STOCK => AFFECTATION => SOCCO => TRANSPORT)

Concernant les véhicules qui ne m'appartiennent pas.

Je facture des frais de gardiennage sous un délai de 15 jours (d'où la colonne F / STOCK).

Un fois l'enlèvement du véhicule effectué, je bascule la colonne L en TRANSPORT. Je fais la MAJ. J'indique manuellement la date et le nom de la compagnie de transport dans l'onglet TRANSPORT.

Dans le cas ou la date de frais de gardiennage est dépassée, je colorie en orange la ligne colonne B/C/D afin de bloquer le véhicule à l'enlèvement. IL y a donc un transfert direct de STOCK => TRANSPORT

Concernant les couleurs:

  • en vert les véhicules CARGO car c'est un client particulier avec un fonctionnement particulier (de A=> I).
  • Colonne G => Provenance des contrats (EST => ORANGE // BLEU => NORD // RILLIEUX ROSE PALE)
  • en orange => Colonne B/C/D les frais de gardiennage.

Le reste n'a pas d'importance. Concernant la migration, si possible je préfèrerais les garder

Concernant les diverses information du fichier STOCK:

Dans la colonne L

=> DOSSIER => Veut dire qu'il y a un soucis sur le dossier donc qu'il est en attente, je ne peux donc pas le transféré en AFFECTATION.

=> FACTURE DIAC => IL me manque le solde de rachat du véhicule.

=> SOLDE => Idem mais pour CARGO

Dans la colonne J et K => Dédié à CARGO => AGIR ou ACTION / PV restitution signé ou non

Voila je pense que je n'ai rien oublié

Ne reste plus qu'à digérer...

Désolé... C'est pour ca que j'avais fait des macros en escalier et j'en ai vraiment ch... pour le faire

Dis-moi, Nico,

Feuille STOCK / colonne L : quel est le traitement à réserver à SUD dans la liste de validation ?

Simplement envoyer directement à VO SUD? Particularités?

A quoi servent les listes de validation, 'STOCK', colonne M ?

A+

Le traitement de SUD depuis la feuille STOCK n'est pas nécessaire. Je passe à 99% par le feuille AFFECTATION et donc très rarement en direct. On peut annuler cette spécificité qui n'est vraiment pas nécessaire.

Oui ça sert simplement à faire un transfert direct.

Les listes de validation sur la feuille STOCK en M ? Tu parles du bouton Mise à jour ? Car cette colonne ne sert à rien mis-à part positionner mon bouton de MAJ. Par contre sur la feuille AFFECTATION, la colonne M sert à indiquer l'affectation et donc la destination des véhicules.

A+

Rechercher des sujets similaires à "fichier macro lent"