Office: Laufzeitfehler '6': Überlauf

In folgendem Code Round(Zeile / 520 * 100, 0) funktioniert die Variante1 einwandfrei. Stelle ich die Berechnungsreihenfolge um wie in Variante2 Round(100 * Zeile / 520), liefert VBA ab dem Wert Zeile = 328 "Laufzeitfehler '6': Überlauf". Offenbar bildet VBA intern bei "100 * Zeile" einen Zwischenwert im INTEGER Format und kommt damit nicht klar. Aber rein syntaktisch sollte der Code doch korrekt sein.
Übrigens funktioniert Variante2 auch, wenn ich Zeile als LONG deklariere.

Was mich interessiert: ist der Code syntaktisch korrekt oder nicht?
Solche Effekte können ja an gottweißwo Stellen auftreten, an denen niemand mit rechnet, oder?

Code:

 

du weist das Ergebnis einer Integer Variablen zu, das geht nicht.
Für Zeile würde ich immer Long nehmen da 1.04.5756 Zeilen möglich sind.

 

Der Datentyp Integer kann nur werte bis 32.768 verarbeiten

Deine Zahl 328 mit 100 multipliziert ergibt 32.800 ...von daher geht das nicht...

Als Programmierer sollte man dafür sorgen, daß genau so was nicht passieren kann...

 

Danke für eure bisherigen Anworten,
ABER: der Ausdruck in der Klammer 100 * Zeile / 520 ist in diesem Beispiel IMMER 32768.

Die einzig denkbare Erklärung ist nach wie vor, dass beim Abarbeiten des Ausdrucks in der Klammer bereits auf INTEGER Grenzen geprüft wird, obwohl der Ausdruck noch gar nicht fertig interpretiert wurde. Das würde aber bedeuten, dass gemäß der Anregung von Hajo_Zi ÜBERALL auf der linken Seiten von Ausdrücken und Funktionen sicherheitshalber das größte denkbare Teilergebnis als Werteumfang abgebildet werden sollte, also nur mit LONG bzw. DOUBLE arbeiten. Das ist kein effizienter Umgang mit Arbeitsspeicher, aber davon haben wir ja wohl alle anscheinend mehr als genug.

 

lese Bitte den ersten Beitrag

100 * Zeile ist größer 32 tausend.

 

Moin Dippe!
Was sagt der geneigte Kenner zu dieser Formel?
Müsste doch einwandfrei funktionieren?
Schließlich ist das ERGEBNIS im Zahlenraum von Excel angesiedelt:

	A	B
1	3,00E+307	#ZAHL!

Zelle	Formel
A1	=3E+307
B1	=A1*1000/5200

Excel Tabellen im Web darstellen >>

 

Hallo Hajo_Zi,

wenn ich richtig informiert bin, Funktioniert eine Funktion wie folgt, Beispiel Runden:

Round(Zeile / 520 * 100, 0)

Zuerst wird der übergebene Parameter ausgewertet:

328/520*100 = 63,0xxx

Dann wird die Funktion ausgeführt : Round(63,0xxx, 0) ergibt 63.

Oder?

 

Überdenke mal mein Beispiel in #6

 

das ist eine andere Rechnung?
Teilergebnisse dürfen nicht über der Grenze sein. Du brauchst uns aber nicht glauben.
Warum hast Du dann gefragt?
Ich bin dann raus, da mir nicht geglaubt wird.

 

Der Fehler kommt nicht, weil 'Zeile' als Integer definiert ist, sondern wegen Deiner Integer-Variablen 'Fortschritt'

Dieser Variablen willst Du ein Formelergebnis zuweisen, bei der während der Berechnung die Grenzen eines Integer-Wertes überschritten werden...
Fortschritt = Round(100 * Zeile / 520, 0)

Jetzt verstanden?

 

Hallo RFP63NEU,

genau, das Beispiel zeigt, dass das Problem "unterwegs" beim interpretieren des Ausdrucks passiert. In Deinem Beispiel überschreiten wir da im ersten Schritt den Zahlenbereich und es kracht, bevor der Ausdruck fertig interpretiert wird. Wenn ich Deine Formel in B1 Umstelle: =A1/5200*1000 dann funktioniert es.

Bleibt für mein Problem nur die Erklärung, dass Excel beriets VOR Auswertung des Ausdrucks rechts der Klammer den Zahlenbereich der Variablen links der Klammer annimmt und auch Zwischenergebnisse gegen diesen Bereich prüft. Wenn man das weiß, muss man sich halt immer auf die sichere Seite stellen.

Ich habe nochmal VBA Definitionen angeschaut: WorksheetFunction.Round liefert als Ergebnis DOUBLE, VBA Round zeigt hierzu keine Angabe, dürfte aber ähnlich funktionieren. Ich vermute daher weiterhin, dass der Interpreter bereits bei Teilergebnissen gegen den Zieltyp prüft. Solange hier keine Überschreitung erfolgt, ist er zufrieden, da die Schleife ja bis 327 einwandfrei läuft. ber so ganz konsequent und sauber ist das m.E. nicht gelöst.

Ich nehme also mit: Bei Variablen, die ihre Werte aus Ausdrücken und/oder Funktionen erhalten, sicherheitshalber den maximalen Wert einen Zwischenergebnisses berücksichtigen. Im zweifelsfalle die Reihefolge der Operanden intelligent wählen. Das sind dann wieder Basics, wie ScoreFun sagt: "Als Programmierer sollte man dafür sorgen, daß genau so was nicht passieren kann..."

 

Hallo Ralf, habe eben nach Schreiben erst Deinen letzten Beitrag gesehen. Wir sind uns einig. Vielen Dank.

 

Hallo Ralf,

Im folgenden Beispiel kommt auch dann der Fehler, wenn Fortschritt als Long definiert ist (Excel 2010).
Code:

Das war neu für mich.

Gruß
Aloys

 

Moin Aloys!
Der Bundesjogi würde jetzt sagen:
"Högscht interessant!" *boah
By the way:
Es gibt ja diverse Codes im Netz, die eindeutig belegen, dass VBA auf long/double optimiert ist.
Deshalb verwende ich in Produktivdateien grundsätzlich diese Datentypen!
Und ja: Geschwindigkeit oder Speicherprobleme sind bei mir eigentlich nie ein Thema.

Gruß Ralf

 

Das war neu für mich.

Gruß
Aloys

Huch...das war mir bislang auch fremd...haha