Office: (Office 2013) Runden mit Access (Sonderfall)

Hallo,

ich habe schon Google gewaltig durchforstet, aber zu meinem speziellen Problem leider keine passende Lösung gefunden.

Es geht darum die Anzahl der Backbleche (Pro Backblech passen 8 Brezen drauf) zu ermitteln, wenn z.B.

18 Brezen benötig werden sollen 3 Bleche ausgegeben werden
222 Brezen --> 28 Bleche
12 Brezen --> 2 Bleche
4 Brezen --> 1 Blech

usw.

Ich verwende in einer Abfrage "Bleche: Runden(([M23]+[M8])/8)+1"

Das kommt meinem Wunsch bis jetzt am nähesten hin, aber bei 222 Brezen werden 29 Bleche und NICHT 28 ermittelt.

Hat da jemand einen Tip für mich?

Danke!

:)

 

Was sicher funktioniert:
AnzahlBrezel \ BrezelProBlech + Abs(CBool(AnzahlBrezel Mod BrezelProBlech))

Es gibt aber sicher noch einfachere Lösungen.

Achte aber darauf "\" für die Division zu verwenden und nicht "/".
LG Markus

 

Code:

 

Danke Markusxy! Es funktioniert!

Du hast mir sehr geholfen!

*Smilie


@ebs17

Danke für die Hilfsbereitschaft, aber da die erste Lösung bereits hilft, will ich Deine nicht mehr testen. Ich bin aber sicher, daß sie auch funktioniert.

 

Hallo
222 / 8 -> 27.75 + 1 = 28.75
evtl. Runden

 

\@Eberhard
Gute Lösung, um einen Tick effizienter als mein Vorschlag.

LG Markus

 

\@Eberhard

Interessant finde ich das
Cbool(a mod b > 0) oder (a mod b > 0) schneller ist als Cbool(a mod b)
Hast wer dazu eine Erklärung?

LG Markus

Edit:
Ich hab jetzt bei einer größeren Stichprobe gesehen, dass doch praktisch kein Unterschied besteht.

 

Hallo,

eine andere Lösung um aufzurunden wäre auch
Code:

Freundliche Grüße
readonly

 

Freundliche Grüße
readonly

Spannend,
interessant wäre noch eine Erklärung zur Arbeitsweise, auch wenn ich es aufgrund der schlechten Performance eher nicht einsetzen würde.

Int(-0.1) = -1
Int(-1) = -1
Int(-1.1) = -2
Int(0.9) = 0
LG Markus

 

Performancebetrachtungen an Hand der sehr übersichtlichen Berechnung sind im konkreten Fall sehr ambitioniert. Es werden wohl kaum 50 Mio Backvorgänge in einem Vorgang geplant - 50 Mio als geschätztes Beispiel für eine Zahl, wo Unterschiede in den Varianten vermutlich messbar oder gar spürbar werden.
Wenn man es aber genau wissen will, muss man in der Tat messen.

Allgemeine Betrachtung dazu:
Michael Zimmermann schreibt in "Datenbankperformance mit Microsoft Access / Grundlagen für optimales Tabellen- und Abfrage-Design" (Link in erster Zeile meiner Fußnote):

Die bewegten Bytes sind nicht nur abhängig davon, wie lang eine Anweisung ist oder wieviele Operationen dabei eingesetzt werden, sondern auch, mit welchem Aufwand an sich eine Operation daherkommt.

Im gleichen Dokument wird eine Einordnung von Operationen sowie Datentypen von sparsam zu aufwändig gezeigt. Diese gilt zwar für die Verwendung in Jet-SQL, ist aber sinngemäß durchaus übertragbar auf viele weitere Fälle. Nähern kann man sich der Sache, wenn man sich vor Augen hält, dass Speichern- und Rechnenoperationen nach wie vor auf dem Binärsystem (Einsen und Nullen) basieren.

Bei Wahlmöglichkeit würde ich mich also immer in den oberen Fächern der genannten Operationen und Datentypen bedienen und hätte da einen berechtigten Glauben, mich überwiegend im optimalen Bereich zu bewegen.

 

Hallo markusxy,

man könnte meine o. a. Formel auch so schreiben:
Code:

Also die Berechnung in eine Minuszahl umwandeln, dann mit der Int-Funktion abrunden, dann wieder in eine Pluszahl zurückwandeln.

Die Performanceunterschiede zwischen den verschiedenen, in den anderen Beiträgen angeführten Lösungen sind minimal:
Code:

Es wird generell aufgerundet, d. h. ist das Ergebnis AnzahlBrezeln / StckProBlech z. B. negativ, dann wird von -27,75 auf -27 aufgerundet, was bei den in den anderen Beiträgen angeführten Formeln auch so ist.

Will man positive Zahlen aufrunden (27,75 -> 28) und negative Zahlen abrunden (-27,75 -> -28), dann wäre nachfolgendes eventuell eine Lösung:
Code:

 

\@readonly,
wie es funktioniert ist klar, nur nicht was Int genau macht.

Aber die VBA Hilfe gibt zwar Hinweise, aber Erklärung (mathematische) keine.
Ich nehme das mal als gegeben, obwohl es mir schon wichtig wäre.

Performance:

Code:

Code:

Bei mir dauerts also zweimal so lange.
Komisch ist, dass mein uralter Rechner obwohl ich 10x soviel Durchläufe habe wie du, in etwa gleichviel Zeit benötigt.

Die Performance ist für mich nur wichtig, wenn ich das ganze in eine allgemeine Funktion gießen möchte, was ich auch getan habe.

Dann sieht das ganze ja wieder anders aus.

Funktion Aufrufen:

Code:

LG Markus

Edit:
Ich werde mir jetzt noch eine eigene Int Funktion über Auswertung der Mantisse erstellen. Mal sehen wie performat die arbeitet.

 

Vorsicht: Der Overhead durch die übergelagerte Funktion kann Performancevorteile einer Gestaltung egalisieren bis hin zur gegensätzlichen Wirkung, gerade bei solchen schmalen Aktionen.

 

Ich weiß, aber ohne Testen kommt man nicht drauf.
Hab das mal bei einer Abfrage beobachtet, die durch einen Index um ein vielfaches langsamer statt schneller wurde.

LG M

 

\@markusxy
Code:

Kannst Du den verwendeten Zeitnehmer und das Ergebnis näher beschreiben?

Mir bekannte Zeitnehmer gehen nicht tiefer als in den Millisekundenbereich. Wenn ich das Ergebnis als Sekunden interpretiere, liegt die Genauigkeit 8 Potenzen darunter??