Limit Code-Größe

[RainerW]

Hallo,

ich habe folgendes Problem.

In einer Exceldatei habe ich mehrere Subs in einem Modul. Das Ganze ist sehr umfangreich (insgesamt ca. 4000 Programmzeilen).

Die Subs werden über einen Schedulerjob angestoßen. Neuerdings erhalte ich die Meldung am Server mit dem Schedulerjob:
"Fehler beim Kompilieren: Prozedur zu groß"

Wenn ich das ganze lokal auf meinem Rechner laufen lasse, erhalte ich die Fehlermeldung nicht.

Beide Maschinen laufen mit Excel 2010, auf dem Server allerdings die 32bit Version, auf meinem Rechner 64bit.

Ich kann natürlich (mit einigem Aufwand) die kritische Sub in mehrere Subs aufteilen um das Problem zu umgehen. Allerdings wüsste ich gerne, wo genau mein Problem liegt. Dazu finde ich leider nirgendwo folgende Informationen:
- Unterschied in der 64k Kompilatgröße bei 32-/64bit Versionen?
- wo kann ich die Größe des erzeugten Kompilats feststellen (Anzahl von Zeilen sind ja beliebig und haben nichts mit dem ausführbaren Code zu tun)?

Ich bin über jeden Hinweis dankbar!

Vielen Dank und Grüße
Rainer

[lupo1]

Vermutlich kannst Du den Code auch inhaltlich stark kürzen.

Keine Antwort auf Deine Code-Größen-Frage.

[RainerW]

Hallo Lupo1,

Danke für den Hinweis. Wie immer ist der Code optimierbar. Da ich aber bis auf wenige Ausnahmen keinen Makrorecorder-Code verwende und versuche, einigermaßen effektiv zu programmieren, ist das Kürzungspotential mit meinen Mitteln nicht stark sondern ehr mäßig.

Ich bin schon dabei, die betroffene Prozedur in zwei aufzuteilen. Mich interessiert einfach nur, warum das auf einem Rechner funktioniert und auf dem andern nicht (mich machen Zufallsergebnisse immer ein wenig nervös). Ferner würde ich auch gerne sehen, inwieweit ich die 64k bereits ausnutze. Dann könnte ich bzw. man reagieren, bevor eine Auswertung auf die Bretter geht.

BG, Rainer

[maninweb]

Hallo,

meines Wissens ist die 64K-Begrenzung unabhängig von der Bit-Version für Office.
Was den Fehler betrifft, schau' mal hier...

https://support.microsoft.com/en-us/help/983044/-compile-error-procedure-too-large-error-message-when-you-try-to-run-a-vba-macro-in-a-32-bit-version-of-an-office-2010-program

Besagt letztlich, entwickle die VBA-Anwendung mit einer 32-Bit-Office-Version.
Das Aufteilen kann zudem nicht schaden.

Gruß

[RainerW]

Hallo maninweb,

vielen Dank für Deine Hilfe!

Das Ergebnis ist aber ein Armutszeugnis seinens Microsoft. Als Entwickler soll ich eine 32bit Version zum Entwickeln benutzen, kann also keine 64bit optimierte Version nutzen, wenn es z. B. um große Datenmengen geht. Das geht nicht an mich.

Aber was soll es, Microsoft wird das soviel interessieren wie der berühmte Sack Reis, der in China aufplatzt ...

Nochmal Danke

BG, Rainer

[maninweb]

Hallo Rainer,

naja, man muss auch bedenken, dass VBA zu einer Zeit entwickelt wurde, wo von 64 Bit noch geträumt wurde.
VBA ist in diesem Sinne letztlich eine veraltete Technologie, weshalb MS - so denke ich mal - nicht mehr allzu
viel darin investieren wird und sich eher um die Pflege kümmert, wie z.B. Anbinden neuer Excel-Features
oder Sicherheitspatches usw. Und VBA bleibt uns auch sicherlich noch eine ganze Weile erhalten.

Gruß

[RainerW]

Hallo maninweb,

ja ja, ich weiß - ich bin mal wieder zu wenig nachsichtig 

Bin halt nur der Meinung, dass dies einem modernen System nicht gerecht wird.

Natürlich will ich nicht nachtreten - aber die 64k Grenze erinnert mich doch stark an MS-DOS 
Scheint wirklich schon etwas in die Jahre gekommen zu sein.

Was ist denn die Alternative - außerhalb mit den Produkten des .net-Framework (z. B. vb.net) Add-Ins programmieren? Oder gibt es bereits Planung von Nachfolgeprodukten zu VBA?

BG
Rainer

[mumpel]

Hallo!

Die 64-bit-Version von Office ist m.E. auch nicht besser als die 32-bit-Version, solange man nicht mit Dateien jenseits der 2GB arbeiten muss. Die 64-bit-Version hat sogar mehr Nachteile als Vorteile. Z.B. wenn es um Add-Ons geht. Es gibt nur extrem wenige Softwarehersteller die ihre Office-Add-Ons für 64-bit-Office optimieren, die allermeisten laufen nur unter einem 32-bit-Office. Zudem ist die 64-bit-Officeversion unter Windows 64-bit auch nicht wirklich schneller als die 32-bit-Officeversion.

Zudem gibt es nicht wirklich viele Anwender die so umfangreich programmieren dass die Module die 64kbit sprengen. 64kbit ist schon reichlich Code. Vielleicht solltest Du schauen ob Du etwas optimieren kannst.

Gruß, René

[RainerW]

Hallo René,

das mit der 64bit Version hat sich bei mir ergeben, da ich in unserem Migrationsprojekt unseres ERP-Systems sehr große Datenmengen ausgelesen, geprüft und bewegt habe. Aktuell Programmiere ich ein Projektcontrolling auf Basis von SQL-Durchgriffen auf die SQL Datenbank des ERP-Systems. Als Abfallprodukt ist aktuell eine Kapazitätsplanung auch noch auf Basis des Projektcontrollings dran.

Da kommen große Mengen Programmcode aber auch Daten zusammen. Das Ganze läuft als Nachtjob im Scheduler.

Abschließend empfiehlt EPlan (System zur Erstellung von Elektroplänen) - hier lese ich Excel-Elektrostücklisten in unser ERP-System ein - auch noch die 64bit Version.

Da komme ich nicht um die 64bit Version herum und ein "Mischbetrieb mit 32bit" ist ja bekanntlich nicht möglich.

Mein Problem habe ich dahingehend gelöst, dass ich die betroffene Prozedur auf zwei Prozeduren aufgeteilt habe.

Wie gesagt, mein Code kann sicherlich optimiert werden, habe mich aber zum Aufsplitten entschieden.

Vielen Dank für Deinen Hinweis

Herzliche Grüße
Rainer

[maninweb]

Hallo Rainer,

Jep, VBA ist schon etwas in die Jahre gekommen. Alternativen, die ohne größeren Aufwand einsatzbar sind gibt's meiner
Meinung eigentlich keine. Es wären da...

- VSTO, Excel-Add-Ins mit .Net entwickeln, setzt die Installation von Libraries voraus, macht nicht jedes Unternehmen.
- Office JS (JavaScript), im kommen, bei weitem nicht so leistungsfähig wie VBA, das dauert noch.

Gruß

[mumpel]

Office JS wird doch hoffentlich parallel laufen, und VBA aus Kompatibilitätsgrunden noch ein paar Jahre/Jahrzehnte erhalten bleiben? Wenn VBA stirbt dann fliegt bei mir Office raus. Mit JS schlage ich mich nicht mehr rum, keine Lust mehr noch etwas anderes zu lernen.

[maninweb]

Hallo René,

Office JS läuft parallel zu VBA. Und VBA bleibt uns sicherlich noch eine Weile erhalten,
nur Investitionen in VBA dürfte man meiner Meinung nach nicht erwarten.

Gruß