VBA-Code in zentrale "Server-XLA" auslagern
Jörg Eisenträger
Hallo,
ich habe ein umfangreiches Workbook mit viel VBA-Code als XLT im
Netzwerk hinterlegt. Dateigröße ca. 1 MB. Täglich werden einige XLS
daraus gemacht und im Netzwerk abgelegt. Um Speicherplatz zu sparen habe
ich die Idee, den VBA-Code in eine XLA auszulagern (macht 400 KB
weniger).
Geht das überhaupt? Ist das sinnvoll? Was muss ich dabei beachten?
Da an dem Code immer wieder etwas verbessert wird, möchte ich die XLA
nicht dezentral auf jedem Client installieren (in XLStart u.ä.), sondern
nur einmal im Netzwerk hinterlegen. Der Code der XLT (bzw. XLS) soll
dann die XLA laden.
Geht das? Ist das sinnvoll?
Können mehrere User gleichzeitig dieselbe "Server-XLA" geladen haben?
Gibt es elegantere Alternativen, um VBA-Code zentral auszulagern und bei
Bedarf zu laden?
Gruß
Jörg
--
LPs auf CD brennen - so geht's: http://www.joergei.de/
Bei Antworten per E-Mail bitte den Unterstrich aus der Adresse entfernen.
BorisX
>ich habe ein umfangreiches Workbook mit viel VBA-Code als
XLT im
>Netzwerk hinterlegt. Dateigröße ca. 1 MB. Täglich werden
einige XLS
>daraus gemacht und im Netzwerk abgelegt. Um Speicherplatz
zu sparen habe
>ich die Idee, den VBA-Code in eine XLA auszulagern (macht
400 KB
>weniger).
>
>Geht das überhaupt? Ist das sinnvoll? Was muss ich dabei
beachten?
>
>Da an dem Code immer wieder etwas verbessert wird, möchte
ich die XLA
>nicht dezentral auf jedem Client installieren (in XLStart
u.ä.), sondern
>nur einmal im Netzwerk hinterlegen. Der Code der XLT
(bzw. XLS) soll
>dann die XLA laden.
>
>Geht das? Ist das sinnvoll?
>Können mehrere User gleichzeitig dieselbe "Server-XLA"
geladen haben?
>
>Gibt es elegantere Alternativen, um VBA-Code zentral
auszulagern und bei
>Bedarf zu laden?
Vorab: Ich hab keine Ahnung.
Aber das möchte ich doch mal loswerden:
Deine Frage liest sich wie ein Fluss - schlüssig von vorne
bis hinten. Dazu mit einem wirklich
aussagekräftigen 'Betreff'. Könnte man imho in ein
Lehrbuch aufnehmen. Kompliment!
Ich hab übrigens kein schlechtes Gewissen, hier OHNE
Lösung zu posten, da unsere VBA-Cracks (Melanie und
Konsorten) dein Problem (sofern denn lösbar) mit
Sicherheit schon richten werden;-))
Also: Übe dich im Zweifel nur in etwas Geduld;-) (und
wehe, die Cracks lassen mich jetzt hängen...;-) )
--
Grüße Boris
Reiner Wolff
> Aber das möchte ich doch mal loswerden:
> Deine Frage liest sich wie ein Fluss - schlüssig von vorne
> bis hinten. Dazu mit einem wirklich
> aussagekräftigen 'Betreff'. Könnte man imho in ein
> Lehrbuch aufnehmen. Kompliment!
Eine klitzekleine Einschränkung: Die Angabe der zur Verfügung stehenden
Version(en) fehlt.
>> ich habe ein umfangreiches Workbook mit viel VBA-Code als XLT im
>> Netzwerk hinterlegt. Dateigröße ca. 1 MB. Täglich werden einige XLS
>> daraus gemacht und im Netzwerk abgelegt. Um Speicherplatz zu sparen
>> habe ich die Idee, den VBA-Code in eine XLA auszulagern (macht 400
>> KB weniger).
Bist Du sicher, dass das nicht mehr ausmacht/machen müßte?
Hast Du schon mal probiert, sämtliche Tabellenblätter einzeln in eine neue
Arbeitsmappe zu übernehmen, um so evtl. die Speichergröße der Datei zu
verringern? Denn manchmal blähen sich ja die lieben Excel-Dateien ein wenig
auf.
>> Geht das überhaupt?
Ja.
>> Ist das sinnvoll?
Ja.
>> Was muss ich dabei beachten?
Sehr schwierig so allgemein zu beantworten.
>> Da an dem Code immer wieder etwas verbessert wird, möchte ich die XLA
>> nicht dezentral auf jedem Client installieren (in XLStart u.ä.),
>> sondern nur einmal im Netzwerk hinterlegen. Der Code der XLT (bzw.
>> XLS) soll dann die XLA laden.
>> Geht das?
Ja.
>> Ist das sinnvoll?
Weiß ich nicht so recht. Eine XLA ist ja die typische Dateiendung für ein
Add-In und Add-Ins werden normaler Weise im Add-In-Manager eingetragen und
können dort vom Benutzer auch wieder ausgetragen werden. Natürlich geht das
auch via VBA, aber ich glaube nicht, dass man sich die Arbeit machen muss.
Wir benutzen diese Technik selbst, allerdings lagern wir den Code in eine
XLS-Datei aus, die wir dann über Menü Fenster - Ausblenden prinzipiell auf
unsichtbar stehen haben. Sämtliche Funktionalitäten sind dann ausgelagert
und müssen natürlich dann von der "Erst-Datei" aufgerufen werden.
>> Können mehrere User gleichzeitig dieselbe "Server-XLA" geladen haben?
Ja, mehrere User können recht problemlos dieselbe Datei geladen haben. Da
diese die Quellcodedatei ja eh nicht bearbeiten sollen, öffnest Du die
Datei einfach schreibgeschützt. Das könnte dann beim Laden der "Erst-Datei"
zB so aussehen:
Private Sub Workbook_Open()
Workbooks.Open "Mappe1.xls", , True
Application.Run "Mappe1.xls!IchBinÖffentlich"
End Sub
Schwierig wird es lediglich dann, wenn man zwischen beiden Arbeitsmappen
eine "Kommunikation" braucht, zB weil auf diese Art und weise nun
vielleicht mehrere "Erst-Dateien" in der selben Excel-Instanz geöffnet
werden können und der Hintergrund-Code so programmiert sein muss, dass er
damit keine Probleme hat, etc.
>> Gibt es elegantere Alternativen, um VBA-Code zentral auszulagern und
>> bei Bedarf zu laden?
Ja, gibt es. Man könnte eine DLL-Bibliothek erstellen, die dann einfach
über die Verweise in die Vorlagendatei mit eingebunden wird. Der Vorteil
liegt u.a. darin, dass der Code darin bereits kompiliert vorliegt und das
Laden/Entladen einer zusätzlichen Arbeitsmappe entfällt. Allerdings
benötigst Du für sowas mehr als VBA. Dafür würde zB VB weiterhelfen können
oder auch jede andere vollständige Programmiersprache.
> Ich hab übrigens kein schlechtes Gewissen, hier OHNE
> Lösung zu posten, da unsere VBA-Cracks (Melanie und
> Konsorten) dein Problem (sofern denn lösbar) mit
> Sicherheit schon richten werden;-))
> Also: Übe dich im Zweifel nur in etwas Geduld;-) (und
> wehe, die Cracks lassen mich jetzt hängen...;-) )
Ich bemühe mich.
Mit ein wenig Glück hilft es weiter und mit noch viel mehr Glück ist es
auch noch richtig ;-)
Greetinx aus Kiel
Reiner
--
Manche Computer kosten ein Vermögen - andere nur den Verstand.
Ahmed Martens
Jörg Eisenträger wrote:
> Hallo,
>
> ich habe ein umfangreiches Workbook mit viel VBA-Code als XLT im
> Netzwerk hinterlegt. Dateigröße ca. 1 MB. Täglich werden einige XLS
> daraus gemacht und im Netzwerk abgelegt. Um Speicherplatz zu sparen
> habe ich die Idee, den VBA-Code in eine XLA auszulagern (macht 400 KB
> weniger).
>
> Geht das überhaupt? Ist das sinnvoll? Was muss ich dabei beachten?
>
> Da an dem Code immer wieder etwas verbessert wird, möchte ich die
> XLA nicht dezentral auf jedem Client installieren (in XLStart u.ä.),
> sondern nur einmal im Netzwerk hinterlegen. Der Code der XLT (bzw.
> XLS) soll dann die XLA laden.
>
> Geht das? Ist das sinnvoll?
> Können mehrere User gleichzeitig dieselbe "Server-XLA" geladen haben?
>
> Gibt es elegantere Alternativen, um VBA-Code zentral auszulagern und
> bei Bedarf zu laden?
>
> Gruß
> Jörg
ich möchte Dir einmal mein Vorgehen in unserem Büro darstellen.
Also wir haben alle Vorlagen (*.XLT) auf dem Server (\Vorlagen)liegen.
Daneben gibt es in diesem Ordner Vorlagen auch noch die XLStart
(\Vorlagen\XLStart\) auf dem Server. In Excel wurde jetzt auf jedem
Rechner in den Optionen eingestellt, dass immer die XLStart mitgeladen
werden soll.
In diesem Verzeichnis XLStart werden jetzt alle *.XLA abgelegt, die
immer beim Excelstart mitgeladen werden. Hier in diesen XLA habe ich
wirklich zentrale Programme liegen. Für jeden Anlass (Anwendung) eine
eigene. Bis jetzt sind es allerdings nur 2. Diese sind aber doch schon
recht umfangreich. Ein langsamerer Start ist aber nicht bemerkbar.
Da jeder Anwender immer alle XLA mitaufruft brauche ich mich um eine
AddIn-Installation nicht mehr kümmern. Durch die Server-Verwaltung hat
auch jeder immer die aktuellste XLA-Programme.
Alle Funktionen/Subs sind aus jedem Tabellenblatt abrufbar. Jede
Funktion kann auch auf dem Tabellenblatt, also in einer Zelle,
verwendet werden (=MeineFunktion()).
NACHTEIL:
Der einzige mir bekannte Nachteil der sich einstellte ist der, dass
wenn Du an den XLA-Dateien arbeitest, was wirklich jederzeit möglich
ist, und ein anderer hat auch Excel geladen, so mußt Du die XLA erst
unter einem anderen Namen speichern, da sie ja jetzt schreibgeschützt
ist.
Auch darfst Du auf *keinen* Fall vergessen die XLA-Datei *immer* aus
dem VBA-Editor zu speichern, weil sonst wirklich alle Änderungen
verschwunden sind.
Ich habe mich für dieses Vorgehen entschieden, weil ich die Wartung und
Pflege jetzt viel einfacherer finde. Außerdem wird jetzt wirklich in
der Tabelle nur das gespeichert was auch wirklich wegen der Events auch
dort hingehört.
Gruß Ahmed
Reiner Wolff
> NACHTEIL:
> Der einzige mir bekannte Nachteil der sich einstellte ist der, dass
> wenn Du an den XLA-Dateien arbeitest, was wirklich jederzeit möglich
> ist, und ein anderer hat auch Excel geladen, so mußt Du die XLA erst
> unter einem anderen Namen speichern, da sie ja jetzt schreibgeschützt
> ist.
Diesen Nachteil könntest Du vielleicht dadurch umgehen, dass Du den
XLA-Dateien auf Dateiebene das Attribut 'Schreibgeschützt' verpasst. Nun
sind alle Clients nur noch in der Lage die Datei schreibgeschützt zu öffnen
und dürften Dich nicht weiter beim Aktualisieren stören. Arbeiten solltest
Du an diesen Dateien sowieso nicht, dazu nehme ich immer eine Kopie der
Datei, um den Produktivbetrieb nicht zu stören.
> Ich habe mich für dieses Vorgehen entschieden, weil ich die Wartung und
> Pflege jetzt viel einfacherer finde. Außerdem wird jetzt wirklich in
> der Tabelle nur das gespeichert was auch wirklich wegen der Events auch
> dort hingehört.
Wohl dem der keine Laptops mit zu versorgen hat *seufz*.
HTH
Greetinx aus Kiel
Reiner
--
Assembler ist eine Methode, Programme, die zu langsam laufen,
so umzuschreiben, daß sie überhaupt nicht mehr laufen.
Jörg Eisenträger
Hallo Boris,
>> Aber das möchte ich doch mal loswerden:
>> Deine Frage liest sich wie ein Fluss ... Kompliment!
Danke. :-)
Hallo Rainer,
>Eine klitzekleine Einschränkung: Die Angabe der zur Verfügung stehenden
>Version(en) fehlt.
Ja, das hatte ich vergessen und gleich nach dem Posten bemerkt.
Nachtrag: Netzwerk-Clients mit Windows 2000 oder Windows XP pro und MS
Excel 2000 oder XP oder 2003.
>>> habe ich die Idee, den VBA-Code in eine XLA auszulagern (macht 400
>>> KB weniger).
>Bist Du sicher, dass das nicht mehr ausmacht/machen müßte?
Zumindest verringert sich die Dateigröße um so viel, nachdem ich
sämtlichen Code per VBA gelöscht habe.
>Hast Du schon mal probiert, sämtliche Tabellenblätter einzeln in eine neue
>Arbeitsmappe zu übernehmen, um so evtl. die Speichergröße der Datei zu
>verringern?
Auf diese Art werden aus ursprünglich 1,1 MB jetzt 320 KB (prima), d. h.
ohne VBA Code und leider auch ohne alle ActiveX-Objekte, weil die ja so
nicht mit kopiert werden (überhaupt nicht prima).
Lassen sich alle ActiveXes eventuell per Code in die neue Mappe kopieren
und richtig platzieren mit allen ihren Eigenschaften?
>Wir benutzen diese Technik selbst, allerdings lagern wir den Code in eine
>XLS-Datei aus, die wir dann über Menü Fenster - Ausblenden prinzipiell auf
>unsichtbar stehen haben. Sämtliche Funktionalitäten sind dann ausgelagert
>und müssen natürlich dann von der "Erst-Datei" aufgerufen werden.
Sehr schön.
>>> Können mehrere User gleichzeitig dieselbe "Server-XLA" geladen haben?
>Ja, ... schreibgeschützt (öffnen).
Beruhigend.
>Schwierig wird es lediglich dann, wenn man zwischen beiden Arbeitsmappen
>eine "Kommunikation" braucht, zB weil auf diese Art und weise nun
>vielleicht mehrere "Erst-Dateien" in der selben Excel-Instanz geöffnet
>werden können und der Hintergrund-Code so programmiert sein muss, dass er
>damit keine Probleme hat, etc.
Oh, guter Hinweis. Dann werde ich wohl vorerst das mehrfache Öffnen der
Erst-Datei abblocken müssen.
>>> Gibt es elegantere Alternativen, um VBA-Code zentral auszulagern und
>>> bei Bedarf zu laden?
> ... DLL-Bibliothek
OK, davon z. Z. nix Ahnung. Entfällt vorläufig. Programmierung ist
überhaupt nicht mein Haupt-Job.
Danke für Deine Antwort.
Jörg Eisenträger
Hallo Ahmed,
>> habe ich die Idee, den VBA-Code in eine XLA auszulagern
>> sondern nur einmal im Netzwerk hinterlegen.
>ich möchte Dir einmal mein Vorgehen in unserem Büro darstellen.
>Also wir haben alle Vorlagen (*.XLT) auf dem Server (\Vorlagen)liegen.
>Daneben gibt es in diesem Ordner Vorlagen auch noch die XLStart
>(\Vorlagen\XLStart\) auf dem Server. In Excel wurde jetzt auf jedem
>Rechner in den Optionen eingestellt, dass immer die XLStart mitgeladen
>werden soll.
Danke. Interessant und sicher nützlich für Euch. Wir sind leider kein
"Büro", sondern haben ca. 500 MA, z. T. mit Notebooks. Meine Vorlage
müsste von jedem PC aufrufbar sein, aber täglich würden dass nur sehr
wenige tun. Auch werden die PCs immer mal wieder ausgetauscht. Deshalb
tendiere ich dazu, die XLA (oder auch eine ausgeblendete XLS) mit Code
nur bei Bedarf zu laden.
Reiner Wolff
>>>> habe ich die Idee, den VBA-Code in eine XLA auszulagern (macht 400
>>>> KB weniger).
>> Bist Du sicher, dass das nicht mehr ausmacht/machen müßte?
> Zumindest verringert sich die Dateigröße um so viel, nachdem ich
> sämtlichen Code per VBA gelöscht habe.
Schon klar.
>> Hast Du schon mal probiert, sämtliche Tabellenblätter einzeln in eine neue
>> Arbeitsmappe zu übernehmen, um so evtl. die Speichergröße der Datei zu
>> verringern?
> Auf diese Art werden aus ursprünglich 1,1 MB jetzt 320 KB (prima), d. h.
> ohne VBA Code und leider auch ohne alle ActiveX-Objekte, weil die ja so
> nicht mit kopiert werden (überhaupt nicht prima).
> Lassen sich alle ActiveXes eventuell per Code in die neue Mappe kopieren
> und richtig platzieren mit allen ihren Eigenschaften?
Ohne zu wissen, um welche ActiveXes es sich da handelt und wo Du sie
untergebracht hast: Nö.
Ein auf dem Tabellenblatt befindliches ActiveX sollte doch eigentlich
mitkopiert werden. Ein auf einem Formular befindliches ActiveX solltest Du
zusammen mit deinem VBA-Code via Exportieren und späteres Importieren
bewegen können, aber da der VBA-Code doch eh in eine andere Arbeitsmappe
ausgelagert werden soll, ist es doch auch nicht weiter schlimm, dass er
beim kopieren der Tabellenblätter nicht mitgenommen wird, oder?
>> Schwierig wird es lediglich dann, wenn man zwischen beiden Arbeitsmappen
>> eine "Kommunikation" braucht, zB weil auf diese Art und weise nun
>> vielleicht mehrere "Erst-Dateien" in der selben Excel-Instanz geöffnet
>> werden können und der Hintergrund-Code so programmiert sein muss, dass er
>> damit keine Probleme hat, etc.
> Oh, guter Hinweis. Dann werde ich wohl vorerst das mehrfache Öffnen der
> Erst-Datei abblocken müssen.
Sag bescheid, wenn es Dir gelungen ist, denn der Benutzer öffnet eine
weitere Datei
- über Menü Datei - Neu
- über Menü Datei - Öffnen
- Strg-O zum aufrufen des Öffnen-Dialoges
- über ein Symbol oder einen CommandButton, den er sich selbst programmiert
hat
- über eine Verknüpfung (auf dem Desktop oder sonstwo)
- durch Doppelklick im Explorer
- über eine sonstige Funktion, die mir derzeit nicht einfällt
Wir haben es damals auch so versucht, ein mehrfaches Öffnen abzublocken.
Inzwischen glaube ich, es für mehrere Dateien lauffähig zu programmieren
macht weniger Arbeit. Dazu ist es bei uns allerdings nie gekommen, wir
leben nach wie vor mit ein paar Einschränkungen bzw. Fehlern zB beim Öffnen
über den Explorer.
HTH
Greetinx aus Kiel
Reiner
--
Smash forehead on keyboard to continue . . .
Ralf Pfeifer
> Wohl dem der keine Laptops mit zu versorgen hat *seufz*.
Hast Du es mal mit den Offline-Files von Win2000 / XP
versucht? Du legst auf den Notebooks fest, dass die
Verzeichnisse mit Vorlagen und allgemeinen Infos auch offline
zur Verfügung gestellt werden.
Beim nächsten Netzwerk-Kontakt sollten sich dann die
Dateien syncronisieren.
Gruß, Ralf.
Ralf Pfeifer
> Hallo,
>
> ich habe ein umfangreiches Workbook mit viel VBA-Code als XLT im
> Netzwerk hinterlegt. Dateigröße ca. 1 MB. Täglich werden einige XLS
> daraus gemacht und im Netzwerk abgelegt. Um Speicherplatz zu sparen habe
> ich die Idee, den VBA-Code in eine XLA auszulagern (macht 400 KB
> weniger).
>
> Geht das überhaupt? Ist das sinnvoll? Was muss ich dabei beachten?
>
> Da an dem Code immer wieder etwas verbessert wird, möchte ich die XLA
> nicht dezentral auf jedem Client installieren (in XLStart u.ä.), sondern
> nur einmal im Netzwerk hinterlegen. Der Code der XLT (bzw. XLS) soll
> dann die XLA laden.
>
> Geht das?
Es gibt folgende Möglichkeit, bei der Du sogar den Code
in einer XLS-Datei lassen kannst:
1. Öffne in der XLT-Dazei den VBA-Editor (Alt+F11)
2. Im Menü Extras -> Verweise trägst Du die Datei mit dem
Code ein.
Eventuell hier den UNC-Pfad (\\Server\Pfad\...) angeben,
wenn nicht alle das gleiche Netzlaufwerk haben.
3. Alles speichern, fertig!
Reiner Wolff
>> Wohl dem der keine Laptops mit zu versorgen hat *seufz*.
> Hast Du es mal mit den Offline-Files von Win2000 / XP
> versucht? Du legst auf den Notebooks fest, dass die
> Verzeichnisse mit Vorlagen und allgemeinen Infos auch offline
> zur Verfügung gestellt werden.
> Beim nächsten Netzwerk-Kontakt sollten sich dann die
> Dateien syncronisieren.
Ja, danke für den Vorschlag.
Offline-Dateien sind aus verschiedenen Gründen keine alternative:
1.
die Funktion steht bei unseren Win98-Clients nicht zur Verfügung
2.
Offline-Dateien sind leider profilabhängig (zumindest was die
Zugriffsberechtigung angeht). Das führt insbesondere bei auswärtigen
Zusammenschlüssen der Laptops zu "externen Netzwerken" zu Problemen.
3.
Offline-Dateien arbeiten leider unter Win2000-Server nicht mit einem DFS -
verteilten Dateisystem zusammen.
4.
Alles auf dem Server zu belassen - ohne einen Terminal-Server zu nutzen -
erhöht die Netzlast bei einer größeren Nutzeranzahl doch erheblich. Daher
kann es durchaus sinnvoll sein, den Programmcode von Programmen auch auf
dem jeweiligen Rechner zu installieren.
Aus diesen Gründen haben
wir ein eigenes Verteilungssystem programmiert, das - so simpel es auch ist
- ganz wunderbar dafür sorgt, dass die Clients eigentlich immer auf dem
aktuellen Stand sind.
Trotzdem nochmal schönen Dank für den Denkanstoß.
Greetinx aus Kiel
Reiner
--
Wenn Architekten so bauen würden, wie Programmierer Ihre
Programme machen, könnte ein einziger Specht ganze Städte zerstören.
Jörg Eisenträger
Hallo Reiner,
>Ohne zu wissen, um welche ActiveXes es sich da handelt und wo Du sie
>untergebracht hast: Nö.
Option-Buttons und normale Schaltflächen, auf dem Tabellenblatt.
>Ein auf dem Tabellenblatt befindliches ActiveX sollte doch eigentlich
>mitkopiert werden.
Diese Aussage hat mich veranlasst, noch einmal genauer zu suchen und
siehe da ... Ich hatte bisher nichts davon gewusst (halt nie
gebraucht), dass man ein Blatt kopieren kann mittels rechter Maustaste
auf die Blatt"zunge". Ich hatte immer alle Zellen selektiert (Klick oben
links); und dabei gingen die ActiveX-Dinger nicht mit. Aber jetzt haut
es hin. Danke. Die Datei ist nun wieder größer: 520 KB. Das heißt die
Hälfte ging für den Code drauf.
>> Dann werde ich wohl vorerst das mehrfache Öffnen der
>> Erst-Datei abblocken müssen.
>
>Sag bescheid, wenn es Dir gelungen ist
Naja, vielleicht auch nur eine Hilfskrücke: Idee: Man könnte verhindern,
dass eine weitere Datei geöffnet wird, deren Dateiname mit dem String
anfängt, mit dem auch der Erstdateiname anfängt. Zumindest heißt bei mir
eine mit der Vorlage.XLS geöffnete neue Datei zuerst immer Vorlage1.xls,
dann Vorlage2.xls usw.
In unserem Fall ist auch der neue Name, unter dem gespeichert werden
soll, vorgegeben und fängt mit dem gleichen String an.
Jörg Eisenträger
Hallo Ralf,
>> die Idee, den VBA-Code in eine XLA auszulagern
>> und ...
>> nur einmal im Netzwerk hinterlegen. Der Code der XLT (bzw. XLS) soll
>> dann die XLA laden.
>Es gibt folgende Möglichkeit, bei der Du sogar den Code
>in einer XLS-Datei lassen kannst:
>
> im VBA-Editor, Menü Extras -> Verweise trägst Du die Datei mit dem
> Code ein.
Cool.
Erspart mir die Routine zum Laden der XLA durch meinen XLT-Code.
Danke. Ich liebe das Usenet.