nicht angemeldet
Hi!
Du brauchst einen Superuser für Administrationszwecke. [...]
Okay, das hab ich verstanden. Obwohl, ein DB-Zugriff erfolgt später nur über php-scripte, nicht mehr über phpmyadmin. Dabei haben natürlich auch Kunden die Möglichkeit, z.B. ihr Passwort nachträglich immer mal wieder zu ändern.
Nein, du betrachtest grad nur deine produktiven Anwendungen. Administrative Zugriffe wirst du jedoch ebenfalls benötigen, und sei es, um Kunden zu löschen oder ihnen ein neues Passwort zu setzen, weil sie es vergessen haben.
Ob mein PMA fehlerhaft läuft, kann sicher sein.
Daran glaub ich nicht, das würde bei der Vielzahl an Installationen schnell auffallen.
In schattenbaum.net schreibt die Autorin Claudia u.a., dass sie lieber auf dem Server testet, als auf dem lokalen Rechner, eben weil es da zu Problemen kommen kann. Ich werde das jetzt mal so hinnehmen und später auch auf dem Server alles nochmal testen.
Jein. Am Produktivsystem zu entwickeln und zu testen, kann bei einer Fehlbedienung auch schnell mal nach hinten losgehen. Besser ist es, ein möglichst vergleichbares System zu Testen zu verwenden.
Ich habe gerade eine Abfrage gestaltet, um zu verhindern, dass sich ein Kunde mit einem bereits existierenden Nicknamen nochmals registriert. Sieht so aus:
Sowas macht man anders, weil sonst zwischen der Abfrage und dem Anlegen eine zeitliche Lücke entsteht, in der sich durch parallel laufende Handlungen Änderungen ergeben, nach denen das Abfrageergebnis nicht mehr stimmt. Besser ist, einen Unique-Index auf die Nichnamen-Spalte zu legen und auf gut Glück ein Eintragen zu versuchen. Wenn kein Fehler auftrat, ist alles in Ordnung, und der neue Nickname wurde angelegt. Wenn das DBMS eine Unique-Constraint-Verletzung meldet, gab es den Namen schon. Du musst beim Auswerten der Fehler auf genau diese Meldung testen, so dass du dem Anwender sagen kannst, dass er einen anderen Namen wählen soll.
Lo!
MudGuard