Hallo,
ich habe ein Loginformular. Das passt soweit, sprich es prüft ob Passwort übereinstimmt für den User, ob der User selbst existiert, alles gut soweit. Beiläufig viel mir dann auf, dass wenn ich einen User eintrage und ich return drücke der Login ohne Passwort geht :-[. Den Code dafür habe ich mal vor längerer Zeit über ein YT-Video gefunden und integriert. Wie macht man das bzw. wie muss man den Code ergänzen, damit er ein leeres Passwortfeld NICHT akzeptiert?? Hier der aktuelle Code.
Private Sub cmdLogin_Click()
Dim rs As Recordset
Set rs = CurrentDb.OpenRecordset("tblBenutzer", dbOpenSnapshot, dbReadOnly)
rs.FindFirst "UserID='" & Me.txtBenutzername & "'"
If rs.NoMatch = True Then
Me.lblFalscherBenutzer.Visible = True
Me.txtBenutzername.SetFocus
Exit Sub
End If
Me.lblFalscherBenutzer.Visible = False
If rs!Passwort <> Me.txtPasswort Then
Me.lblFalschesPasswort.Visible = True
Me.txtPasswort.SetFocus
Exit Sub
End If
Me.lblFalschesPasswort.Visible = False
DoCmd.OpenForm "frmMenueseite"
DoCmd.Close acForm, "frmLogin"
End Sub
Für Hilfe diesbezüglich wäre ich dankbar.
Hi,
vielleicht hilft:
If rs!Passwort <> nz(Me.txtPasswort, "") or nz(Me.txtPasswort, "") = "" Then 'abbrechen
Ist sichergestellt, dass die Sub "cmdLogin_Click" überhaupt aufgerufen wird?
Harald
Moin, jetzt mal auf die schnelle..
If rs!Passwort <> Me.txtPasswort or IsNull(me.TxtPasswort) Then
Könnte man auch über eine Gültigkeitsregel des Feldes realisieren.
Hoffe kannst was mit anfangen.
Grüße
... und wenn man statt auf Ungleichheit auf Gleichheit prüft, was ja eigentlich der Logik der Anforderung entspricht, entfällt auch die Besonderheit bei Null-Werten. :)
Hi,
ich vermute mal, dass ein weiteres Problem entstehen kann, wenn grosse und kleine Buchstaben im Kennwort zu unterscheiden sind.
Hier könnte StrComp helfen.
Harald
Ich würde das Click Event erst ermöglichen, wenn Benutzername und Passwort ausgefüllt sind.
Im After Update Event von beiden würde ich folgende Methode ausführen.
sub LoginEnable()
cmdLogin.Enabled = Len(Nz(Me.txtBenutzername)) > 0 And Len(Nz(Me.txtPasswort)) > 0
end sub
Dann ist sichergestellt, dass der restliche Code einwandfrei funktioniert.
Hallo Andreas,
If rs!Passwort <> Nz(Me.txtPasswort) Then
oder der Vorschlag von Lachtaube.
Gruß
Josef
Hallo zusammen,
vielen Dank für die Info und Hilfe. Ich habe mich für die Lösung vom Markus entschieden, auf beide Textfelder das After_Update Ereignis zu nutzen. Das funktioniert auch tadellos. Ich frage mich nur, ob dies sinnvollerweise auf den Loginbutton gelegt werden kann/sollte, dass beim klicken geprüft wird, ob die beiden Textfelder befüllt sind (zwecks Übersicht). Da ich aber VBA mäßig total abhängig bin was die Hilfe angeht, bin ich mit der Lösung aber vollauf zufrieden und würde den Teufel tun mich zu beschweren :).
Vielen Dank noachmal
Gruß Andreas
Jeder, der an Dein Backend kommt, kann z. Bsp. mit Excel alle Benutzernamen und Passworte im Klartext (auch ohne VBA-Kenntnis) auslesen. Da fragt man sich natürlich nach der Sinnhaftigkeit solcher Konstrukte schlechthin.
Hallo Andreas,
Private Sub cmdLogin_Click()
Dim rs As Recordset
Set rs = CurrentDb.OpenRecordset("tblBenutzer", dbOpenSnapshot, dbReadOnly)
If Nz(Me.txtBenutzername, "") = "" OR Nz(Me.Passwort, "") = "" Then
Msgbox "Beide Felder müssen ausgefüllt sein!"
Else
rs.FindFirst "UserID='" & Me.txtBenutzername & "'"
'dein weiterer Code
End if
End Sub
gruss ekkehard
Hallo,
und auch noch mal den Hinweis, dass ein einfacher Textvergleich nicht zwischen Groß und Kleinbuchstaben unterscheidet.
Passwort = PASSWORT = passwort = PassWort
Ist das gewollt ?
Hi,
Zitat von: MzKlMu am Januar 18, 2018, 16:44:57
noch mal den Hinweis, dass ein einfacher Textvergleich nicht zwischen Groß und Kleinbuchstaben unterscheidet.
Passwort = PASSWORT = passwort = PassWort
Lösungsvorschlag gibt es in #4
Harald
Hallo,
sorry erst mal, dass ich vorhin
Zitat....ich frage mich nur, ob dies sinnvollerweise auf den Loginbutton gelegt werden kann/sollte, dass beim klicken geprüft wird.....
erwähnt habe. Das war unüberlegt, da natürlich alle anderen Antworten mehr oder weniger genau das ja vorgeschlagen haben. Markus hatte ja nur eine andere Vorgehensweise vorgeschlagen. Also sorry for that, war mal wie so oft unüberlegt geantwortet :(.
@Klaus
Zitatund auch noch mal den Hinweis, dass ein einfacher Textvergleich nicht zwischen Groß und Kleinbuchstaben unterscheidet.
Passwort = PASSWORT = passwort = PassWort
Ist das gewollt ?
Nein Klaus, das ist natürlich nicht gewollt, das war eben nicht in dem "gefundenen" Code inkludiert.
@bahasu
ZitatLösungsvorschlag gibt es in #4
Wie du selbst gelesen hast, habe ich den Code "gefunden", angepasst soweit ich konnte und wusste und dann verwendet. strcomp "einbauen" wird wohl eher schwierig bis unmöglich für mich, muss ich zugeben :(.
@Ekkehard
danke für den "genauen" Integrationshinweis bezüglich Prüfung über den Loginbutton.
@Lachtaube
ZitatJeder, der an Dein Backend kommt, kann z. Bsp. mit Excel alle Benutzernamen und Passworte im Klartext (auch ohne VBA-Kenntnis) auslesen. Da fragt man sich natürlich nach der Sinnhaftigkeit solcher Konstrukte schlechthin.
Danke für deinen Hinweis, auch wenn ich jetzt nicht weiß wie ich das wiederum "vermeiden" könnte :(.
Gruß Andreas
Hi,
Zitat von: derilzemer am Januar 18, 2018, 18:38:56
strcomp "einbauen" wird wohl eher schwierig bis unmöglich für mich, muss ich zugeben :(.
da bin ich aber optimistischer: Das schaffst Du! :)
Aus der access-Hilfe folgt zum Aufruf: StrComp(string1, string2[, compare])
Für "compare" setzt Du ein: "vbBinaryCompare" ' 0 Führt einen binären Vergleich durch.
Als Ergebnis dieser Funktion erhältst Du:
0 ' => string1 entspricht string2
Daneben gibt es noch -1 und +1 und Null als mögliches Ergebnis: Versuch macht kluch. ;)
Harald
Hi,
Zitat von: derilzemer am Januar 18, 2018, 18:38:56
Danke für deinen Hinweis, auch wenn ich jetzt nicht weiß wie ich das wiederum "vermeiden" könnte :(.
Da ich die Vorzüge eher in access2003 als in a2016 sehe, kann ich mir nicht verkneifen, dass winzigweich in dem alten Programm das Berechtigungskonzept hat, das genau regelt, wer was darf. Ob das ein für Dich nutzbarer Weg ist, kannst nur Du entscheiden.
Harald
PS
Bitte vermeide zukünftig einen zu langen Titel.
Zumindest bei mir erscheint beim Speichern eines Beitrags immer eine Fehlermeldung, dass der Titel zu lang ist.
Hi Harald,
ist die Umstellung von
Option Compare Database
with
Option Compare Binary
auch ein Lösungsansatz? Das bewirkt doch, dass die Form auf der man das anwendet (in dem Fall die LoginForm) Case sensitive wird, Ergo auch das Passwortfeld. Oder ist das eine Lösung für "Dilettanten"?.
Gruß Andreas
Den Mut Deinen Vorschlag zu testen, wirst Du doch wohl haben und z. Bsp prüfen ob "A" = "a" ist.
Hi,
wenn wenn du dich auf meine Frage beziehst, ja den Mut hatte ich und ich habe es auch probiert und es geht ja auch. Frage war ja nur ob diese Lösung auch Sinn macht.
Du sei mir nicht böse, aber ich weiß nicht was ich dir getan habe. Deine Kommentare mir gegenüber jedenfalls sind in der Regel auf tsss ausgerichtet, warum auch immer. Dass ich deinem Level nicht entspreche, dafür kann ich nun mal nichts und ich muss deinem Level auch nicht entsprechen. Das wäre wohl das gleiche wenn ich dich Dinge aus meinen Beruf Frage, da wäre das Wissen wohl auch etwas flacher. Ich würde dir gegenüber deswegen aber kein tsss ausgeben. Sorry wegen meiner Meinung.
Gruß Andreas
Hi,
Zitat von: derilzemer am Januar 18, 2018, 19:14:39
Option Compare Database
with
Option Compare Binary
auch ein Lösungsansatz?
jetzt habe ich als bekennender a2003 Fan gelernt, dass a365 auch etwas Gutes hat.
Leider kann ich dazu keinen Input liefern, da ich abends keinen Zugriff auf den a365 bzw. a2016 Rechner habe.
Harald
Hi,
also den Tests nach zufolge, geht das gut. Welche Schwächen man sich damit dann wieder ins Haus holt kann ich aktuell nicht beurteilen. Ich habe das umgestellt und hätte jetzt vermeintlich "nur" noch das Problem was Lachtaube angesprochen hat, dem auslesen der User und Passwörter via Excel. Ich hatte mal zu Anfang mit encrypt herumgefummelt, das scheiterte dann aber daran, dass wenn der User sein PW ändert, dies in der tblBenutzer nicht übernommen wurde mit dem encryptverfahren. Dann wäre zumindest das Passwort nicht in Klartextformat auszulesen. So bin ich beim Klartextverfahren hängen geblieben :(.
Gruß Andreas
Hallo,
@Harald
Zitatjetzt habe ich als bekennender a2003 Fan gelernt, dass a365 auch etwas Gutes hat.
was meinst Du damit ?
Dieses "Option Compare Binary" ?
Das gibt es schon seit mindestens A2000.
Andreas, Du hast mir nichts getan. Ich bin eben etwas zynisch in meinen Anmerkungen. Will damit aber eigentlich den Fragesteller zum selbstständigen Denken und Handeln anregen. Gefühlte 99% aller Fragen wurden schon einmal in Access-Foren gestellt und beantwortet, und auf gefühlte 85-90% der Fragen findet man bei donkarl.de eine ausreichende Erklärung.
Wenn ich gefühlt in jedem zweiten Beitrag eines Fragestellers über längere Zeit herauslesen, Entschuldigung, aber VBA kann ich nicht, den Code zum Problem müsst ihr mir schon schreiben, drängt sich mir irgendwann die Frage, ob Du überhaupt Ambitionen hast, VBA erlernen zu wollen. In meinen Antworten kann ich mir dann zynische Aussagen auch nicht verkneifen.
Aber selbst so einfache Dinge wie zuvor, solltest Du auch als Anfänger in Sachen VBA selbst erfolgreich erforschen können. Und wenn man selbst etwas auf die Beine stellt, fühle ich mich zumindest (und Du vermutlich doch auch) viel wohler, als wenn es von anderen abkupfert ist.
PS: Die Zynik hätte ich mir im Beitrag wohl verkniffen, wenn Du z. Bsp. geschrieben hättest, ich habe in einem Modul im Modulkopf Option Compare Binary verwendet und durch MsgBox "A" = "a" herausgefunden, dass die beiden Ausdrücke als ungleich betrachtet werden. Kann man sich darauf generell verlassen?
Gestern habe ich in einem anderen Access-Forum jemand auf eine ähnliche Frage geantwortet. Der Fragesteller hat es erfolgreich geschafft, eine Berichtsausgabe auf den aktuellen Datensatz des Formulars zu beschränken. Allerdings wurde der Bericht ausgedruckt, was er anscheinend nicht wollte. Nun kam die Frage auf, ob durch Angabe von acViewPreview der Ausdruck unterbunden wird. Meine Antwort darauf war, er solle den Drucker ausschalten und die Sachlage prüfen, um im Zweifelsfall Papier zu sparen, wenn er seiner Informationsquelle nicht traut. Du bist also nicht allein. :)
PPS: ... und meine Anmerkung zum Speichern von Passworten ist ernst gemeint. Jeder, der Zugang zu einer nicht-passwortgeschützten Access-DB hat, kann gespeicherte Passworte im Klartext auslesen. Teste es, indem Du in Excel die Zugangstabelle über das Band Daten importierst. Als Benutzer würde mich das Ärgern.
BTW: VBA kannst Du mit Literatur (kann durchaus bis in's Jahr 2000 zureichen, wenn Geld gespart werden soll) oder selbst einem Wiki-Book (Link poste ich gerne bei Interesse) erlernen, wenn man sich selbst an kleinen Anforderungen/Aufgaben versucht.
So, ich hoffe Du kannst weiterhin mit meiner Art umgehen oder teile mir in einer PN oder auch öffentlich mit, dass Dir meine Art auf den Senkel geht, dann unterlasse ich das zukünftig bzw. halte mich aus Deinen Fragen auf Wunsch natürlich auch ganz heraus.
Hi Klaus
Zitat von: MzKlMu am Januar 18, 2018, 20:14:52
Dieses "Option Compare Binary" ?
Das gibt es schon seit mindestens A2000.
Ok, dann hat a365 (das war der erste Link, der bei der Recherche danach auftauchte) ja doch keinen Vorteil. ;D
Jetzt im Ernst: Hatte den Befehl noch nicht eingesetzt, da die obige Funktion für mich den Vorteil hat, dass ich sie gezielter einsetzen kann.
Aber vielleicht irre ich mich auch dabei. Dann gilt halt: Habe keine Ahnung, und davon ganz viel.
Jetzt halte ich mich lieber hier heraus, da ich die Schäden von Friederike aufräumen muss.
Harald
Die Option Compare Anweisung ist i.d.R. das erste, was ich aus Access-Modulen verbanne. vbTextCompare oder vbDatabaseCompare setze ich notfalls dann gezielt ein.
Hi,
danke erst mal für deine ehrliche und offene Antwort.
Zitat von: Lachtaube am Januar 18, 2018, 20:41:41
Andreas, Du hast mir nichts getan. Ich bin eben etwas zynisch in meinen Anmerkungen. Will damit aber eigentlich den Fragesteller zum selbstständigen Denken und Handeln anregen. Gefühlte 99% aller Fragen wurden schon einmal in Access-Foren gestellt und beantwortet, und auf gefühlte 85-90% der Fragen findet man bei donkarl.de eine ausreichende Erklärung.
So, ich hoffe Du kannst weiterhin mit meiner Art umgehen oder teile mir in einer PN oder auch öffentlich mit, dass Dir meine Art auf den Senkel geht, dann unterlasse ich das zukünftig bzw. halte mich aus Deinen Fragen auf Wunsch natürlich auch ganz heraus.
Ich habe mich entschlossen hierüber zu antworten und nicht über PN, eventuell hilft es dem einen oder anderen auch etwas mehr und besser über meine "Ecken, Kanten und Ausbrüche" was zu verstehen. Ich kann deine Reaktion und Denkweise erst mal nachvollziehen.
Zitat
Wenn ich gefühlt in jedem zweiten Beitrag eines Fragestellers über längere Zeit herauslesen, Entschuldigung, aber VBA kann ich nicht, den Code zum Problem müsst ihr mir schon schreiben, drängt sich mir irgendwann die Frage, ob Du überhaupt Ambitionen hast, VBA erlernen zu wollen. In meinen Antworten kann ich mir dann zynische Aussagen auch nicht verkneifen.
ich stimme dir ohne wenn und aber zu, dass schreibe ich oft diesen "Schreibstil" generiere. Dazu hole ich jetzt ein wenig aus, auch wenn wir hier kein Forum für Zwischenmenschliches haben, also schaut alle mal drüber weg :-[.
Ich bin generisch Zimmerer, habe 2001 parallel den Quereinstieg in die EDV gemacht. Angefangen in einem Systemhaus für 1 Jahr, dann in einen Bankenrechenzentrum gewechselt. Erfahrung für den Bereich Switch, Loadbalancing und Firewall gleich 0. Hab mich da reingefuchst, alles gut soweit. Was ich aber nie gelernt habe war proggen, ob VBA oder normales scripten. Siocher, ich kann kleinere Sequenzen, aber das bedeutet wirklich klein: Komplexe Dinge wie solche Logins mit allem drum und dran kam ich nie klar. Ehrlich gesagt, ich habe nimmer die Energie aufgebracht das dann auch noch reinzubringen, das mag vielleicht auch ein Stück weit an meiner Intelligenz liegen, maybe (Klaus wird mich jetzt dann doch mal steinigen weil ich das mit meinen 53 so dahersage).
Die QuartettDB war nichts kleines will ich mal behaupten und auch ziemlich komplex. Vieles an der Oberfläche und Formulare habe ich ja mit Unterstützung auch hinbekommen. VBA blieb aber immer Stiefmütterlich :(. Das soll nicht für alles entschuldigen, aber die Umstände tragen schon ein wenig dazu bei, dass ich das nicht auf die Kette bekomme.
Aber selbst so einfache Dinge wie zuvor, solltest Du auch als Anfänger in Sachen VBA selbst erfolgreich erforschen können. Und wenn man selbst etwas auf die Beine stellt, fühle ich mich zumindest (und Du vermutlich doch auch) viel wohler, als wenn es von anderen abkupfert ist.Ohne wenn und aber ja, stimmt sicherlich. Hin und wieder versuche ich es ja auch, aber stelle relativ schnell fest, dass es wieder zu komplex ist. Dann schlage ich hier im Forum in entschuldigender Form auf, weil ich ja weiß, dass viele so denken wie du. Es ist mir also auch "peinlich"
BTW: VBA kannst Du mit Literatur (kann durchaus bis in's Jahr 2000 zureichen, wenn Geld gespart werden soll) oder selbst einem Wiki-Book (Link poste ich gerne bei Interesse) erlernen, wenn man sich selbst an kleinen Anforderungen/Aufgaben versucht.
Mach mal, poste mir doch mal den Link. Viele sagen, VBA wäre eigentlich dem Tode geweiht. Ist dem so? Lohnt sich der Energieinvest noch in diese Sprache?
PS: Die Zynik hätte ich mir im Beitrag wohl verkniffen, wenn Du z. Bsp. geschrieben hättest, [i]ich habe in einem Modul im Modulkopf [/i][font=courier]Option Compare Binary[/font][i] verwendet und durch[/i] [font=courier]MsgBox "A" = "a"[/font] [i]herausgefunden, dass die beiden Ausdrücke als ungleich betrachtet werden. Kann man sich darauf generell verlassen?[/i]Formulierungen, da war ich auch schon immer nicht unbedingt der Crack :(. Ja, hätte ich ja gleich dazuschreiben sollen, dass ich es getestet hatte und sah, dass es geht.
Meine Antwort darauf war, [i]er solle den Drucker ausschalten und die Sachlage prüfen, um im Zweifelsfall Papier zu sparen, wenn er seiner Informationsquelle nicht traut[/i]. Du bist also nicht allein. :) :) jo wenn man so etwas liest und es einen anderen betrifft versteht man solche Jokes erstaunlicherweise auch viel besser :).
PPS: ... und meine Anmerkung zum Speichern von Passworten ist ernst gemeint. Jeder, der Zugang zu einer nicht-passwortgeschützten Access-DB hat, kann gespeicherte Passworte im Klartext auslesen. Teste es, indem Du in Excel die Zugangstabelle über das Band Daten importierst. Als Benutzer würde mich das Ärgern. Das habe ich auch ernst aufgenommen. Ich habe es getestet und es geht wirklich einfach, auch bei mir :(.
Ich weiss, eigentlich sollte ich in FE und BE trennen, was ich schon hatte. Problem dabei war, dass danach das Bypassthema mit dem BE nicht mehr funktionierte. Es war ganz einfach dies aufzurufen mit dem ByPasskey. Was wäre eine valide Möglichkeit, diesen Transfer von Datzen via Excel zu verhindern? Die DB mit der Option "Mit Kennwort verschlüsseln" solange sie nicht getrennt ist, bringt da ja keine Linderung, oder?
[EDIT 18-01-2018, 21:51] Ich habe das mal mit einer Kopie gemacht, die DB Exklusiv geöffnet und mit PW verschlüsselt. Das geht zwar aber bringt mir nichts, da dann der User das PW ja auch benötigt :(.
Inzwischen hast du ja etwas zu
Option Compare geschrieben, es nicht unbedingt zu verwenden. In erster Linie macht es mal was es soll, aber...? Ich konnte eben nicht ganz herauslesen, warum, also was der Nachteil davon ist. Kannst du mir auch dazu kurz Feedback geben?
Gruß Andreas
Andreas,
zum Programmieren, sollte man anfangs einfach nur die Handlungsabläufe definieren, die man dann in kleine(re) Methoden unterteilen kann. Zusätzlich kommt natürlich bei Access oft noch ein Formular- oder Berichtsobjekt hinzu, das seine Eigenschaften und Methoden hat. Da muss man sich halt etwas einfuchsen (OL-Hilfe lesen, Objektkatalog durchstöbern). Zum Lernen würde ich aber zunächst banalere Dinge angehen, um etwas Gefühl für die Sache zu bekommen. Manche Funktionen gibt es zwar auch schon in VBA, lassen sich zum Lernen aber auch gut selbst programmieren. Ein bekanntes Beispiel wäre z. Bsp. einen Text in der umgekehrten Reihenfolge auszugeben, oder eine Lottozahlen-Ziehung zu simulieren, das Maximum von Zahlenwerten zu ermitteln, Mittelwerte zu berechnen, festellen, ob ein Jahr ein Schaltjahr ist, und viele ähnliche kleine Aufgaben. Dazu kann man dann hier auch gezielt Fragen stellen, wenn einem kein ordentlicher Lösungsweg einfällt, oder seine eigene Routine hier vorstellen und fragen, wie andere Leute die gleiche Aufgabenstellung lösen würden oder verbessern würden.
Also hier zuerst einmal der Link, der in späteren Kapiteln dann Excel-spezifisch wird (da kannst Du ja dann abbrechen, bzw. Kapitel überspringen): VBA in Excel (https://de.wikibooks.org/wiki/VBA_in_Excel)
Nun zur DB. Zur Sicherheit für eine Mehrbenutzerumgebung gibt es eigentlich keine gute Lösung. Was man machen kann, aber dann muss zumindest das VBA-Projekt geschützt sein, ist, das Passwort des Backends fest zu hinterlegen. Die Tabellen des noch ungeschützten Backendends zu verknüpfen, das Backend mit Passwort auszustatten, und sich beim Start des Frontends vor jeglichem Tabellenzugriff, es sich zunutze machen, dass Access Verbindungen cached. D. h., wenn Du jetzt eine Verbindung zum passwortgeschützten Backend öffnest (siehe OpenDatabase-Anweisung in der OL-Hilfe) und die Verbindung in einer globalen Variablen speicherst, können auch die zuvor verknüpften Tabellen des jetzt passwortgeschützten Backends genutzt werden. Bei jedem Umzug des Backends muss aber das Passwort wieder entfernt werden und alle Verknüpfungen müssen erneuert werden. Bei allen anderen Lösungen wird dummerweise das Passwort der verknüpften Tabellen im Klartext in einer Systemtabelle gespeichert. Frei nach dem Motto, wer Sicherheit haben will, kann ja unseren SQL-Server nutzen.
Persönlich stehe ich auf dem Standpunkt, dass die Daten dem Benutzer gehören und er auch vollen Zugriff darauf erlangen sollte. Das Frontend und seine Programmierung betrachte ich eher als das geistige Eigentum des Entwicklers, weshalb man es auch als ACCDE asliefern sollte - dann schraubt kein dritter mehr daran herum (wichtig dabei ist, ein Original zu behalten, denn sonst kann der Entwickler auch nicht mehr schrauben).
Ich kenne ja nun die Umgebungen nicht, unter denen die DB laufen wird. Wenn sichergestellt ist, dass je PC die DB nur von einem Benutzer(-kreis) bedient wird, dürfte es ausreichen, den Anmeldenamen von Windows zu verwenden und nicht großartige Anmeldeprozeduren durchzuführen. Wenn Du auf Passworte bestehst, sollte zumindest ein Hash-Algorhytmus eingesetzt werden, der ohne ein Passwort im Klartext zu speichern auskommt.
Und nun zum Schluß noch:
Option Compare wegzulassen, was gleichbedeutend mit Option Compare Binary ist, ist eine Vorliebe von mir - und man sollte da schon genau wissen, was man macht. Deshalb empfehle ich das nicht generell für jederman. Wie schon vorher von einem anderen Threadteilnehmer (ich glaub, das war Harald) angemerkt wurde, würde bei konsequenter Verwendung der StrComp-Funktion für Zeichenkettenvergleiche die Option Compare Einstellung sowieso überflüssig sein, weil sie ein optionales Argument für die Vergleichsart, wie einige andere Funktionen auch, bereitstellt.
So, und nun geht's ab in die Heia. Gute Nacht.