Md5 per VBA

hal2063

Grünschnabel
Hi,

ich nochmal.
Ich baue privat eine Anwendung für meinen Verein, was dank der DSGVO notwendig wurde.
Die Anwendung hat aufgrund eines Rechtemanagements einen eigenen Login, der MD5-Hashes als kryptografisches Verfahren nutzt.

Die Anwendung soll später innerhalb einer Access2016 Laufzeitumgebung arbeiten, damit die Nutzer kein Access kaufen müssen. Diese Laufzeitumgebung gibt es in 32bit und 64bit.

Dazu habe ich heute auf einem zweiten Rechner (der nie zuvor Access2016 gesehen hat) einige kurze Tests gefahren, ob das alles so läuft wie gewünscht.
Bei der 64bit-Variante funktioniert der Login problemlos (war zu erwarten, denn die Anwendung ist unter 64bit Access2016 gebaut).

Danach habe ich die 64bit-Variante deinstalliert und anschließend die 32bit-Variante installiert.
Hier schlug der Login dann fehl.

Ich habe die vom 64bit-Acess2016 gelieferten Ergebnisse nochmals gegen Built-In-Implementationen (z.B. in PHP) getestet und der Code liefert korrekte Werte, also liegt das Problem meiner Ansicht nach in der 32bit-Laufzeitumgebung. Und vielleicht sogar noch in Kombination mit der eingesetzten Hardware...
... kann also gut sein, daß bei anderen die 32bit-Version problemlos läuft ...

Meinen Entwicklungsrechner hatte ich (natürlich) nicht dabei, so daß ich keinerlei Debugging vornehmen konnte.
Ich vermute die problematische Stelle bei den Funktionen UnsignedToLong() und LongToUnsigned(), da diese als Ersatz für einen "echten" unsigned-Datentypen den Datentyp Double (Fließkommazahl mit doppelter Genauigkeit) benutzen. Da könnte es bei einer 32bit-Implementation theoretisch schon zu Abweichungen gegenüber einer 64bit-Implementation kommen, die sich dann kombinieren und letztendlich zu Rundungsfehlern führen. Schließlich wird bei einem Double der Wert nicht quasi as-is als ein Bitfeld, sondern in Mantisse und Exponent getrennt abgelegt und später wieder rekombiniert.

Bevor ich da jetzt anfange, zu debuggen, was VBA in einer 32bit-Laufzeitumgebung mit dem Modul tatsächlich veranstaltet, frage ich mal kurz in die Runde, ob da schon etwas bekannt ist, was noch nicht den Weg in diesen Thread gefunden hat.

Ich arbeite schon etwas länger als Entwickler (und musste z.B. 2004 PunnyCode für Umlautdomains in Delphi implemetieren), von daher würde es mich nicht wundern, wenn die Addition eines sehr kleinen Terms (z.B. 0,0001) an der/den richtigen Stelle(\n) das Problem beheben würde.

Viele Grüße
Tom
 

hal2063

Grünschnabel
Hallo in die Runde,
Beim Ausführen des Makros erscheint die "Laufzeitfehler 6: Überlauf"- Meldung und die Kennzeichnung der folgenden Code-Zeile:

Anhang anzeigen 64798

Kann ich dieses Problem dadurch lösen, dass ich für eine der in der Implementierung genutzten Variablen einen größeren Variablentyp verwende?

Vorab vielen Dank für Eure Hilfe!
Ist vielleicht etwas spät...

Ein größerer Datentyp hilft hier nicht, denn das Problem liegt woanders: wenn nBlks den Wert 1 hat, wird durch 0 (kullernull) geteilt, das einen Überlauffehler verursacht, wenn die Division durch 0 nicht von einer eigenen Exception abgehandelt wird.