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
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
