Copier vers un fichier Excel fermé

Donc voila ce que j aimerais faire

Fichier actif avec la sheet BLN

je copie les cellules A1F9 vers le sheet "BLN" fichier test3 qui se trouve sur Y et qui est fermé

Sub Copierverstest()

Dim wb As Workbook

Dim ws As Worksheet

With ThisWorkbook.Worksheets("BLN")

.Activate

Range("A1:F9").Select

Selection.Copy

Set wb = Workbooks.Open("Y:\test3.xlsm")

Set ws = wb.Worksheets("BLN")

ws.Activate

Range("A1").Select

ActiveSheet.Paste la sa plante

End With

End Sub

merci de l aide

Bonjour,

Voir si ça convient ... il restera à fermer Test3 si tu n'y a pas d'autres traitements.

Sub Copierverstest()
Dim Ws As Worksheet

Set Ws = Workbooks.Open("Y:\test3.xlsm").Worksheets("BLN")
Workbooks("Base.xlsm").Worksheets("BLN").Range("A1:F9").Copy Ws.Range("A1")
End Sub

ric

Bonjour,

Toujours éviter de Selectionner ou activer, cela ne fait que ralentir VBA...

Sub Copierverstest()
    Dim plg As Range
    Set plg = ThisWorkbook.Worksheets("BLN").Range("A1:F9")
    With Workbooks.Open("Y:\test3.xlsm").Worksheets("BLN")
        .Range("A1:F9").Value = plg.Value 'si tu n'as besoin de reporter que des valeurs
        'si report format, formules, etc. activer ligne ci-dessous et désactiver la précédente
        'plg.Copy .Range("A1")
    End With
End Sub

Si tu n'as besoin que d'un report de valeur, la 1re méthode, sans copier-coller est la plus rapide.

Si tu dois absolument copier (tout reproduire...) tu le fais en une ligne !

Cordialement.

Merci pour cette premiere aide qui me guide doucement vers la solution

Sub Copierverstest2()

Dim Ws As Workbooks

Set Ws = Workbooks.Open("Y:CCER\Controleurs CCER\LTR\activite\test3.xls")

Workbooks("test.xlsm").Worksheets("BLN").Range("A1:F9").Copy Ws.Worksheets("BLN").Range("A1") j ai une erreur

Workbooks("test.xlsm").Worksheets("CDO").Range("A1:F9").Copy Ws.Worksheets("CDO").Range("A1")

End Sub

egalement comment refermer de suite le fichier test3 unload test3 ?

Tu ne suis pas vraiment les conseils qui devraient te simplifier ton code...

Mais le principal problème est que tu types une variable comme collection de classeurs !

Pour fermer un classeur, c'est : .Close False (pour fermer sans enregistrer).

Bonjour à tous,

2 points :

• Pas de S à Dim Ws As Workbook ... sinon tu fais référence à TOUS les classeurs.
• L'oblique inversée manquante ... Open("Y:\CCER\Controleurs ...

Sub Copierverstest2()
Dim Ws As Workbook

Set Ws = Workbooks.Open("Y:\CCER\Controleurs CCER\LTR\activite\test3.xls")
Workbooks("Base.xlsm").Worksheets("BLN").Range("A1:F9").Copy Ws.Worksheets("BLN").Range("A1")
Workbooks("Base.xlsm").Worksheets("CDO").Range("A1:F9").Copy Ws.Worksheets("CDO").Range("A1")

End Sub

ric

bonjour à tous

à quoi sert de copeir vers un classeur fermé ?

il vaut mieux attendre qu'on l'ouvre, ce qui met à jour les données (il y a de multiples manières de créer des "transferts" de données, VBA étant fortement déconseillé)

oui, bon, il faut parfois un petit clic pour actualiser.

très fiable.

bon travail à tous

amitiés

Hello jmd ! Toujours en croisade !

On ne copie pas dans un classeur fermé ! C'est pour ça qu'il l'ouvre...

bonjour

salut MFerrand

c'est pas une croisade, c'est que je pense vraiment que VBA est un logiciel qui a fait son temps. Et que 99,99% des questions ayant trait à VBA doivent se résoudre sans VBA mais avec les fonctions d'Excel. Notamment les "récentes" (qui ont bientôt 10 ans tout de même ! )

Je suis atterré de voir des apprentis en VBA qui ne connaissent pas le menu Données ! ni les TCD !

or 99% des fichiers que nous, tu, je, eux et le monde entier traitent concernent la gestion de données.

Excel est AVANT TOUT un logiciel de traitement de données

Microsoft l'a constaté depuis des lustres, et l'améliore d'abord en vue de ce genre de traitements.

restent quelques fichiers qui font des calculs scientifiques, mais c'est marginal. Voir notre forum pour en être persuadés.

naturellement, les experts en VBA (suivez mon regard ! ) sauront résoudre quasiment toutes les questions. D'ailleurs tu saurais tout résoudre sans Excel, juste avec Word et VBA !

mais est-ce rendre service que d'enseigner VBA ?

la question est dérangeante, je ne veux froisser personne. Mais elle est primordiale.

amitiés, bonne j,ournée à toi et à tous.

Bonjour

j ai essaye ton code

Sub Copierverstest()

Dim plg As Range

Set plg = ThisWorkbook.Worksheets("BLN").Range("A1:F9")

With Workbooks.Open("Y:\test3.xlsm").Worksheets("BLN")

.Range("A1:F9").Value = plg.Value 'si tu n'as besoin de reporter que des valeurs

'si report format, formules, etc. activer ligne ci-dessous et désactiver la précédente

'plg.Copy .Range("A1")

End With

End Sub

ca marche et merci encore

Bonjour,

Utilise les balises Code pour citer du code, cela conserve l'indentation dont le but est de pouvoir lire et travailler plus facilement et plus vite sur du code...

Cordialement.

@jmd : bonjour et à plus tard (pas le temps maintenant...)

@jmd !

Ma préférence a toujours été vers les tableurs, et je n'utilise Word que pour mon courrier administratif... A l'époque du tout début de l'informatisation dans mon entreprise, cela faisait beaucoup rire mon informaticien préféré de me voir faire des traitements de texte sur Multiplan (on était en 86-87).

Et évidemment l'arrivée de VBA n'a fait que renforcer mon inclination.

J'ai exprimé sur je ne sais plus quel sujet les raisons historiques (mon histoire professionnelle perso...) qui m'ont fait laisser de côté les TCD. J'étais alors auditeur et les missions demandées ne nous conduisaient pas à construire des TCD, mais on en disposait en tant que documents fournis par les entités auditées, auxquels on faisait subir divers traitements dans le but de déceler des failles de contrôle interne... S'agissant d'audit opérationnel, notre interlocuteur privilégié était la Production, où opérait une jeune génération produisant force tableaux, sans d'ailleurs les maîtriser vraiment, mais ayant quelque peu oublié un bon nombre de règles de base de traitement du courrier, les auditeurs étant généralement des anciens ayant opéré à la Production... Ceci expliquant sans doute cela, nous bombarder d'éléments qu'ils pensaient sophistiqués en ignorant une bonne partie du b-a-ba de leur matière avait le don de nous irriter quelque peu...

Mais n'étant pas bouché, je me mettrai à voir de plus près les TCD (et la suite), ne serait-ce que pour pouvoir les utiliser en VBA !

Ceci dit, je suis d'accord qu'une majorité de questions concerne des traitements de bases de données, 99% me paraît toutefois très excessif. Et s'il est absurde de se compliquer la vie en voulant opérer d'une façon alors qu'une autre aboutira plus simplement et plus vite au résultat, il ne faut pas rejeter pour autant ce qui relève de la volonté d'aboutir à un résultat personnalisé, cela relève du respect de la liberté de chacun.

Les outils tout prêts que l'on peut utiliser sont des programmes, que quelqu'un (une équipe dans le cas général) a conçu et codé. VBA est un langage informatique, outil permettant de produire des programmes qui, de ce fait seront personnalisés. Il n'y a pas lieu d'y voir une opposition, d'autant que VBA est une version aménagée pour fonctionner avec une application, et donc avec les outils fournis nativement avec l'application.

Aucune obsolescence ne saurait affecter VBA car sa mise à jour suit les évolutions d'Excel, et si Microsoft faisait en sorte qu'il n'en soit plus ainsi, c'est Excel qui en souffrirait.

Je dois dire aussi que mon utilisation perso. étant assez éloignée du traitement de bases de données, comme beaucoup d'utilisations personnelles, VBA est pour beaucoup dans l'utilisation d'Excel hors des entreprises...

NB- Cela ne clôt pas la discussion, on poursuivra ailleurs...

Bonne journée.

re à tous

MFerrand,

ce qui m'étonne le plus c'est que tu travailles sur des fichiers Excel qui ne soient pas des "base de données" !

peux-tu nous en dire un petit peu plus, on est (je suis) curieux

note que les évolutions spécifiques pour Excel 2016 sont liées à 100% à la gestion de données

https://msdn.microsoft.com/fr-fr/vba/office-shared-vba/articles/what-s-new-for-vba-in-office-2016

ej découvre en même temps que toi

amitiés excelliennes

Salut du soir !

Entendons-nous bien, on ne travaille que sur des données ! La frontière est donc quelque peu poreuse. Alors, si l'essentiel de l'activité porte sur l'appel à des bases de données externes, ou si elle consiste en la mise à jour et l'utilisation permanente de bases de données internes, là oui on est sur une utilisation principale base de donnée qui exige la mise en oeuvre de règles communes en la matière.

Ce qui n'exclut pas que l'on puisse y réaliser marginalement des opérations autres...

Si on peut considérer que la gestion de bases de données constitue une activité majoritaire, cela laisse tout de même de la place pour des activités qui ne sont pas principalement centrées sur des bases de données.

Les études statistiques constituent un domaine notable où Excel peut donner sa pleine mesure. Et là contrairement à ce que font certains en tentant d'opérer des études à coups de VBA, je pense que c'est un domaine propre à Excel, sans VBA ou très marginalement. Il est significatif que pour faire en sorte qu'un assemblage de chiffres ne soit pas un nombre dans Excel, il faut prendre les grands moyens, et même lorsque l'on est parvenu à faire en sorte que ce soit du texte, souvent Excel arrive tout de même à calculer avec ! Rien de tel en VBA, ou la conversion en texte se fait assez automatiquement alors que la conversion en nombre doit toujours être explicite. Les outils divers auxquels on peut faire appel à partir de VBA (dico, Forms, Regex, etc.) sont fondés sur des données texte. Et du point de vue calcul, en VBA dès que cela devient un peu complexe il faut faire appel aux fonction Excel, et il est préférable alors pour des études reposant sur des calculs de mettre en oeuvre directement la puissance de calcul d'Excel.

Tu me diras peut-être qu'une étude statistique devra s'appuyer sur une base de données... Je ne suis pas d'accord, il y aura peut-être à prélever des données quelque part au démarrage, qui constitueront la population ou l'échantillon selon le cas, objet de l'étude, mais c'est à partir de là que commence le travail statistique qui n'a plus rien à voir avec la gestion de bases de données.

Le domaine des plannings de tous ordre, tel que je les conçois du moins, échappe à la gestion de base de donnée. Certes on constitue des données et on les conserve en vue de les restituer, on les organise donc à cette fin, donc pas selon les règles habituelles de bases de données, mais de la façon qui permettra de les enregistrer et les restituer le plus rapidement. Un planning est constitué par un support de type calendaire, utilisé simultanément pour la saisie et la consultation, l'enregistrement des saisies doit se faire automatiquement, et de même leur restitution lorsqu'on navigue dans le calendrier, et cela n'est pas réalisable sans VBA...

Et tant qu'on est sur un domaine de dates, s'il prend la fantaisie à quelqu'un de faire de la généalogie sur Excel...

(Entre parenthèses je veux bien reconnaître qu'il s'agit là d'une activité mixte : il va constituer une base de données, qui a intérêt à respecter certaines règles pour demeurer utilisable, mais l'essentiel pour lui demeure son utilisation qui passe par la présentation de données sous une forme généralement personnalisée.)

Alors là le problème va être qu'Excel tout seul est totalement impropre à une telle activité comme à toutes celles portant sur un éventail large de dates... Alors soit il utilise VBA pour corriger Excel, soit il abandonne Excel !

J'en garde en réserve pour les prochaines fois...

re MFerrand

il faut juste se mettre d'accord sur le terme "gestion de données"

pour moi, dès que les saisies sont sous forme de table, c'est de la gestion de données

parfois, elles sont saisies sous forme de tableau déjà croisé (comme certains plannings), il suffit de les décroiser (automatique avec Power Query)

en conséquence, mis à part quelques rares classeurs (avec le solveur par exemple), tout le reste est "données".

Microsoft l'a bien compris et développe de nombreuses fonctionnalités autour de ce sujet, dont Power Query, Power Pivot (données relationnelles automatiques dans Excel ! ) et Power BI, et même des fonctions VBA comme vu plus haut.

bon dimanche à toi et à tous

Bonjour rapide,

Il y a un ajustement de langage et de définition à opérer, mais je pense que nous serions assez vite globalement d'accord sur ce point : ce que tu appelles "mise sous forme de table" me paraît assez facilement se confondre avec ce que je recouvre par "traitement de bases de données", ensuite je fais une distinction selon la place occupée dans l'activité par cette mise sous table...

Alors, s'agissant de planning, je ne stocke jamais les données sous forme de tables ! Je les stocke sous une forme correspondant au mode de visualisation, parce que l'élément important dans ce cas est le temps mis entre le déclenchement et la visualisation effective... Il y a bien des données mais l'action n'est pas du tout centrée sur leur traitement...

Quant à ce que j'ai dit à propos de la généalogie et activités connexes, si je qualifie de "mixte", c'est parce que l'utilisateur a intérêt à stocker ses données sous forme de tables pour en normaliser l'utilisation, mais je ne considère pas que ce soit l'aspect principal qu'il recherche. Sa présentation opératoire sera autre que sous forme de tableau... et au niveau traitement de données il aura surtout à pallier aux carences d'Excel en matière de dates, carences sur lesquelles on ne peu pas faire d'impasse car elles sont au coeur de son activité.

On poursuivra sur un autre sujet...

re MFerrand

j'ai pas trop compris pour le planning. Car alors il suffit de prendre un papier et des crayons de couleur.

pour TOUTES les autres applis, il ets bien entendu que JAMAIS les utilisateurs ne visualisent les données directement dans les tableaux (sauf pour des vérifications rapides). Il y a TOUJOURS une présentation, tantôt avec un TCD, tantôt un GCD, ou aussi Power BI .

qui par exemple aurait l'idée bizarre de lire des factures dans la table des factures ? (en réalité table des lignes de factures). Personne sauf pour des recherches ou des vérif rapides.

on ne veut voir que des factures sous forme pratique, et ensuite pdf, et ensuite des synthèses

pourtant TOUS les progiciels de facturation sont des SGBD.

un logiciel de généalogie fonctionne de manière analogue

il y a des tables de données, qu'on va traiter.

à te relire avec plaisir

Nous sommes d'accord il me semble sur le fait que la meilleure base de données, on ne la voit jamais...

On le serait encore plus si tu admets que si ce que l'on propose à voir ne convient pas au sens esthétique de l'intéressé il faudra bien qu'il personnalise sa visualisation par un programme personnalisé !

@+

re

oui, les bases de données sont ordinairement cachées, mais pas si on utilise Excel, car ce logiciel a l'inconvénient majeur d'entremêler les données et les calculs !

ceci fait sa faiblesse et aussi sa force. Car on a l'impression (fausse) qu'il parvient sans peine à imiter une feuille de papier

mes applis Excel qui supposent des saisies dans Excel, sont TOUTES présentées avec une (des) feuilles de saisie en Tableaux, suivies de feuilles de traitement (TCD...)

on ne saisit JAMAIS dans des cases dispersées dans une feuille

par exemple, il n'y a pas de formulaires de saisie.

c'est simple, hyper-simple, clair, facilement modifiable par

on n'importe qui, fiable dans le temps durant des années, sans souci de versions d'Excel ou de windows.

on met des sécurités où on veut.

quant à faire joli, je m'y emploie, mais sur les feuilles de synthèse, ou d'exploitation des données, pas ou très peu sur les Tableaux de saisie.

note que je fais des progiciels plus élaborés (120 tables, près de 500 vues ou formulaires ou états) mais c'est un SGBD.

les progiciels gérant des données ne sont pas particulièrement beaux (genre CIEL ou EBP par ex). Et je déconseille de demander à les faire beaux, car c'est une perte de temps et surtout d'argent !

un peu comme PPoint, à vouloir tout modifier, on perd du temps et de l'efficacité. Utilisons les modèles de vues et point.

si j'étais un bon vendeur, je vendrais des heures pour faire joli ou sur-mesure.

Effectivement, pour un tableau bien conçu la saisie doit pouvoir être directe... Cependant, l'avantage d'un formulaire, sous forme de UserForm, est indéniable lorsque l'on veut faciliter la saisie et la fiabiliser, elle permet dès le départ d'éliminer des erreurs de saisie, voire d'en rectifier certaines... Et de plus cela permet de ne pas visualiser la base !

Bye !