Ich habe seltsamerweise zuerst an sowas gedacht wie
- Option Base 0 bzw. 1
- Call by Reference
Ich weiß - total verrückt, aber es ist ja auch ein verrücktes Problem
OK, fangen wir hier an:
Ich habe den Wert in eine andere glob. Variable ausserhalb der UserInfo geschrieben. Bei der Anlage weiterer User war dann ( erwartungsgemäß ) nicht nur UserInfo.Password fehlerhaft, sondern auch diese neue Variable.
#1
Was ist createPassword(..) denn für eine Funktion? Worauf ich hinauswill: woher bekommt sie die Daten und wie verarbeitet sie diese? Kann in dieser Funktion überhaupt ein String mit NUL am Anfang generiert werden?
#2
Falls ja: Kommt der String mit NUL am Anfang evtl. von createPassword? Sprich:
szPassword = CreatePassword( ...
print "-->" & szPassword & "<--"
UserInfo.Password = szPassword
print "-->" & UserInfo.Password & "<--"
pwdSave = szPassword
print "-->" & pwdSave & "<--"
ergibt was? Das wird oben schon verneint, aber wenn es das nicht ist, dann:
#3
Getter und Setter. Vielleicht wird über den Lebenszyklus von UserInfo ja Password mehrfach gesetzt oder sonst irgendwie verändert? Getter und Setter bauen, aus Password ein Private pPassword machen und im Getter und Setter jeden Zugriff mitloggen. Du sagtest, die Applikation sei SEHR komplex. Da kann eine Menge schiefgehen...
#4
Datenübergabe im weiteren Sinne. Wird UserInfo oder Teile davon in irgendeiner Form abgespeichert, ex. ein NotesDocument (und wenn auch nur in-memory), wird es exportiert, wird Password im/exportiert (egal warum)? Findet dabei ggf. eine Veränderung statt, die man allein durch LotusScript nicht erklären kann? Ich glaube Dein erstes Posting so verstanden zu haben, daß da allerhand passiert...
Ich denke in die Richtung von Character Sets, unterschiedlichen Datenbank-Settings (Oracle, DB2, whatever), etwas, das in der Lotus Notes Umgebung nicht unmittelbar beeinflußbar ist und das nur auf diesem System (warumauchimmer) anders ist.
Für "Konsumenten" des Paßworts wäre es natürlich auch ganz toll zu wissen, was diese meinen, bekommen zu haben.
#5
Der Kunde hat andere 64bit Systeme im Einsatz, wo das funktioniert? Auch migrierte? Bei Euren Versuchen, die Situation nachzubauen, habt Ihr den alten 32bit Zustand zuerst hergestellt, dann migriert und dann geguckt?
Will sagen - evtl. ist alter Ballast oder das Fehlen davon ein Problem. Irgendeine DLL hat eine andere Version, irgendeine Library ist vom anderen Release-Stand... usw.
Gibt es irgendwelche Unterschiede von diesem Server zu anderen? Physischer Server vs. virtueller, andere SW-Releases, weniger/mehr/andere Zusatzsoftware bzw. Dienste etc.
#6
Wenn es nur um den Notes-Server geht - beim Kunden dieses System außer Betrieb nehmen und den gleichen Notes-Server (quasi 1:1) komplett neu aufsetzen. Wenn Ihr das Problem nicht reproduzieren konntet, dann löst eine funktionale 1:1 Kopie dieses Servers auf anderem Blech bzw. einer anderen VM das Problem?
#7
..in der Chiffrierungsroutine kommt aber nur " 7vcHGY5Wc6vzLMj" an...
Was für eine Chiffrierungsroutine? Ist nur diese vom NUL-Problem betroffen? Wie kommt das Paßwort zu dieser Routine? D.h. *eigentlich* ist alles ok, nur in dieser Routine kommt ein falscher Wert an? Ist das auch Lotus Script? Könnte man da eine andere Form der Datenübergabe testen?
Bei Chiffrieren denke ich an eine externe Funktion (nicht nativ LS), bei deren Aufruf etwas schiefgeht.
Viel Erfolg,
Th.
