Kein Zugriff nach Änderung

[treziman]

Hallo,

als MySql-Anfänger probiere ich gerade sehr viel rum. Nach dem Testen mit einer kleinen DB, habe ich nun eine grosse DB angelegt, wie sie auch später im Net sein soll. Defaultmässig ist kein Passwort angelegt und der User ist 'ROOT'. Nach meinem Infostand ist beides schlecht für den Betrieb auf einer Homepage, und so habe ich ein Passwort angelegt und den User auf 'kunden' geändert. Ich habe XAMPPLITE installiert und wenn ich nun im Control Panel hinter MySql auf 'Admin' klicke, bekomme ich folgende Fehlermeldung:

#1045 - Access denied for user 'root'@'localhost' (using password: NO)

phpMyAdmin hat versucht eine Verbindung zum MySQL-Server aufzubauen, jedoch hat dieser die Verbindung zurückgewiesen. Sie sollten Ihre Einstellungen für Host, Benutzername und Passwort in Ihrer config.inc.php überprüfen und sich vergewissern, dass diese den Informationen, welche Sie vom Administrator erhalten haben, entsprechen.

Also habe ich gegoogelt und auch Hinweise gefunden, nur klappt - wiedermal - nichts.

In der config.inc.php steht defaultmässig:
$cfg['Servers'][$i]['auth_type']            = 'config';
$cfg['Servers'][$i]['user']                 = 'root';
$cfg['Servers'][$i]['password']             = '';
$cfg['Servers'][$i]['AllowNoPassword']      = true;

Habe ich geändert auf:
$cfg['Servers'][$i]['auth_type']            = 'config'; (oder cookie)
$cfg['Servers'][$i]['user']                 = 'kunden';  (oder ROOT)
$cfg['Servers'][$i]['password']             = 'passwort'; (zum testen heisst es wirklich 'passwort')
$cfg['Servers'][$i]['AllowNoPassword']      = true; (oder false - geht beides nicht)

Egal was ich auch ändere, ich bekomme immer die oben zitierte Fehlermeldung. Nach jeder Änderung habe ich im Control Panel den Service MySql gestoppt und neu gestartet. Kurz: ich kann mich nicht mehr unter phpmyadmin einloggen und die DB bearbeiten. Was mache ich falsch? Ich habe das Gefühl, als ob diese config.inc.php gar nicht abgearbeitet wird, obwohl ich, wie gesagt, immer wieder neu starte. Der Pfad stimmt auch: D:/xampplite/phpmyadmin

Gruss
Thorsten

[MudGuard]

Hi,

Egal was ich auch ändere, ich bekomme immer die oben zitierte Fehlermeldung. Nach jeder Änderung habe ich im Control Panel den Service MySql gestoppt und neu gestartet.

Du änderst die Konfiguration für den phpmyadmin und meinst, es hilft, mysql neu zu starten. Es wäre sinnvoller, phpmyadmin neu zu starten ...

cu,
Andreas

[dedlfix]

Hi!

Du änderst die Konfiguration für den phpmyadmin und meinst, es hilft, mysql neu zu starten. Es wäre sinnvoller, phpmyadmin neu zu starten ...

Nein, da gibt es nichts neu zu starten, weil jeder Request bereits ein Neustart ist. Das einzige, wo ein Neustart helfen kann, wäre die Authentifikationstypen cookie und http, dann aber muss der Browser neu gestartet werden, damit er die dort gemerkten Zugangsdaten und Session-ID vergisst. Das ist aber hier nicht der Fall, weil er 'config' und damit die Daten aus der Konfigurationsdatei verwendet, die bei jedem Request neu eingelesen wird.

Lo!

[treziman]

Du änderst die Konfiguration für den phpmyadmin und meinst, es hilft, mysql neu zu starten. Es wäre sinnvoller, phpmyadmin neu zu starten ...

Ich weiss nicht genau, glaube aber, wenn man einer Datenbank ein Passwort hinzufügt und den User ändert, ändert man nicht die Konfiguration für den phpmyadmin, oder?
Im übrigen - mein Fehler: ich habe sicherheitshalber immer BEIDES neu gestartet. Den Apache und MySql.

Gruss
Thorsten

[dedlfix]

Hi!

Ich weiss nicht genau, glaube aber, wenn man einer Datenbank ein Passwort hinzufügt und den User ändert, ändert man nicht die Konfiguration für den phpmyadmin, oder?

Der PMA ist gegenüber dem MySQL-Server ein Client wie alle anderen (PHP-Scripts) auch.

Im übrigen - mein Fehler: ich habe sicherheitshalber immer BEIDES neu gestartet. Den Apache und MySql.

Es ist nur insofern ein Fehler, als dass ein Neustart des Apachen nur dann sinnvoll ist, wenn sich an seiner Konfiguration etwas ändert. Bei Änderungen in von ihm ausgeführten PHP-Scripts ist kein Neustart erforderlich.

Lo!

[treziman]

Ich bin soeben dahintergekommen woran es lag. Vielleicht hilfts dem ein oder anderen mal:

Man muss die cookies im Browser löschen !

Sonst werden wohl die Änderungen in der config.inc.php nicht beachtet.

Danke dedlfix. Du hast mich wiedermal auf den richtigen Weg gebracht, auch wenn Du nichts von cookies erwähnt hast. Ich kam aber durch Dein posting drauf.

Also, 'root' lassen, nur Passwort vergeben?

Gruss
Thorsten

[dedlfix]

Hi!

Man muss die cookies im Browser löschen !
Sonst werden wohl die Änderungen in der config.inc.php nicht beachtet.

Das wäre dann ein Fehler im PMA. Die config.inc.php muss auf alle Fälle beachtet werden, denn sonst wüsste der PMA ja auch nicht, dass er die Daten auf dem Cookie nehmen soll. Wenn da nichts mit cookie aktiviert ist, sollten sie auch nicht weiter beachtet werden.

Also, 'root' lassen, nur Passwort vergeben?

Du brauchst einen Superuser für Administrationszwecke. Ob der nun root heißt, ist nicht von Belang, solange er alle Rechte hat. Aber für Anwendungen braucht man keine vollen Rechte sondern nur die benötigten, weswegen man weitere User mit gezielt vergebenen Rechten anlegt.

Lo!

[treziman]

Du brauchst einen Superuser für Administrationszwecke. Ob der nun root heißt, ist nicht von Belang, solange er alle Rechte hat. Aber für Anwendungen braucht man keine vollen Rechte sondern nur die benötigten, weswegen man weitere User mit gezielt vergebenen Rechten anlegt.

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.

Ob mein PMA fehlerhaft läuft, kann sicher sein. 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.

Bei der Gelegenheit:

Ich habe gerade eine Abfrage gestaltet, um zu verhindern, dass sich ein Kunde mit einem bereits existierenden Nicknamen nochmals registriert. Sieht so aus:

<?php
...

$nickname = "Thorsten";
$ergebnis = mysql_query ("select passwort from kunden where nickname = '$nickname' ");

while ($row = mysql_fetch_object ($ergebnis))
{
$inhalt = $row->passwort;
}

if (isset ($inhalt))
{
Nickname gibts schon; Registrierung wiederholen
}
...
?>

Das funktioniert auch. Als Anfänger frage ich mich aber, ob es nicht einfacher geht. Es müsste z.B. keine (while-)Schleife sein. Unter selfphp, bei den MySql-Funktionen, arbeite ich mich gerade durch. Vielleicht finde ich parallel zu diesem posting ja schon was.

Gruss
Thorsten

[dedlfix]

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!

[treziman]

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.

Aha, dachte ich mir schon, dass es auch einfacher geht.
Unique-Index bedeutet, unter phpmyadmin - Tabellenstruktur - hinten auf das Feld mit dem "U" klicken? Habe ich mal gemacht und die Meldung bekommen:

ALTER TABLE 'kunden' ADD UNIQUE { 'nickname' }

Gruss
Thorsten

[dedlfix]

Hi!

Unique-Index bedeutet, unter phpmyadmin - Tabellenstruktur - hinten auf das Feld mit dem "U" klicken? Habe ich mal gemacht und die Meldung bekommen:

ALTER TABLE 'kunden' ADD UNIQUE { 'nickname' }

Das ist keine (Fehler)meldung sondern nur die Anzeige des Statements, das dazu ausgeführt wird. Zu fast jeder Aktion zeigt der PMA das dafür ausgeführte Statement an. Wenn die Ausführung fehlerhaft war, dann steht da üblicherweise auffällig noch mehr Text da.

Lo!

[treziman]

Das ist keine (Fehler)meldung sondern nur die Anzeige des Statements, das dazu ausgeführt wird. Zu fast jeder Aktion zeigt der PMA das dafür ausgeführte Statement an. Wenn die Ausführung fehlerhaft war, dann steht da üblicherweise auffällig noch mehr Text da.

Das ist schon klar. Ich wollte auch nur sagen, dass es klappte und ich keinen Nicknamen zweimal schreiben kann. So weit, so gut. Ich bekomme allerdings auch keine Fehlermeldung, wenn ich versuche einen Nicknamen zweimal zu schreiben. Nun habe ich wieder gegoogelt, aber kein Beispiel für eine Abfrage nach der Unique-Constaint-Verletzung gefunden. Ich frage nur ungern, weil ich, wenn mir jemand fertige Sachen vorlegt, nichts lerne, aber wie sieht die Abfrage aus? Macht man das auch mit mysql_err() oder so? Ich tappe da jetzt echt im Dunkeln.

Gruss
Thorsten

[dedlfix]

Hi!

Das ist keine (Fehler)meldung sondern nur die Anzeige des Statements, das dazu ausgeführt wird. [...] Wenn die Ausführung fehlerhaft war, dann steht da üblicherweise auffällig noch mehr Text da.
Das ist schon klar. Ich wollte auch nur sagen, dass es klappte und ich keinen Nicknamen zweimal schreiben kann.

Das kann man an dem ALTER-Statement ja noch nicht ablesen.

Ich bekomme allerdings auch keine Fehlermeldung, wenn ich versuche einen Nicknamen zweimal zu schreiben.

Da muss eine Meldung wie folgt ausgegeben werden: #1062 - Duplicate entry 'x' for key 'y'

Nun habe ich wieder gegoogelt, aber kein Beispiel für eine Abfrage nach der Unique-Constaint-Verletzung gefunden. Ich frage nur ungern, weil ich, wenn mir jemand fertige Sachen vorlegt, nichts lerne, aber wie sieht die Abfrage aus? Macht man das auch mit mysql_err() oder so?

Ja, das ist eine Fehlermeldung, die mit dem üblichen Funktionen zu Fehlermeldungen ausgewertet werden kann, als da wären mysql_error() und mysql_errno(). Der Meldungstext variiert und ist für eine maschinelle Auswertung wenig brauchbar, aber es gibt die Fehlernummer, die du eindeutig vergleichen kannst.

Der Code sieht im Allgemeinen so aus, wie man eine Abfrage inklusive Fehlerbehandlung macht. Dazu kommt eine Auswertung dieser einen speziellen Meldung, denn da diese erwartet wird, soll auf sie ja gesondert reagiert werden als auf irgendwelche anderen Fehlerzustände.

Lo!

[dedlfix]

Hi!

Ich frage nur ungern, weil ich, wenn mir jemand fertige Sachen vorlegt, nichts lerne, aber wie sieht die Abfrage aus?

Ich mache das so, dass ich sehr genau untersuche, was für Ergebnisse bei meinem Tun entstehen, indem ich mir die Rückgabewerte der Funktionen und Ausdrücke mit var_dump() o.ä. anzeigen lasse. Diese vergleiche ich dann mit bewusst provozierten Fehlerzuständen. Ich nehme an, da Fehler im Allgemeinen gesellschaftlich nicht besonders angesehen ist, versucht man auch gern beim Programmieren sie zu ignorieren und prüft seine eigenen Programme fast nur mit der gewollten Funktionalität ohne Fehlerzustände herbeizuführen. Man hat etwas mit Mühe erstellt und soll jetzt auch noch versuchen, auf welchem Wege es zerstört werden kann? Doch genau dies ist für ein robustes Programm wichtig. Also "Mut zum Fehler" und Situationen ausdenken, die eigentlich nicht vorkommen sollen und diese nachstellen. Natürlich erfordert auch das Erfahrung und lernt sich nicht von jetzt auf gleich.

Lo!

[treziman]

Ich mache das so, dass ich sehr genau untersuche, was für Ergebnisse bei meinem Tun entstehen, indem ich mir die Rückgabewerte der Funktionen und Ausdrücke mit var_dump() o.ä. anzeigen lasse. Diese vergleiche ich dann mit bewusst provozierten Fehlerzuständen. Ich nehme an, da Fehler im Allgemeinen gesellschaftlich nicht besonders angesehen ist, versucht man auch gern beim Programmieren sie zu ignorieren und prüft seine eigenen Programme fast nur mit der gewollten Funktionalität ohne Fehlerzustände herbeizuführen. Man hat etwas mit Mühe erstellt und soll jetzt auch noch versuchen, auf welchem Wege es zerstört werden kann? Doch genau dies ist für ein robustes Programm wichtig. Also "Mut zum Fehler" und Situationen ausdenken, die eigentlich nicht vorkommen sollen und diese nachstellen. Natürlich erfordert auch das Erfahrung und lernt sich nicht von jetzt auf gleich.

Da hast Du absolut Recht! Leider gehöre ich auch zu dieser Fraktion, die bewusst Fehler einbaut und sich dann anschaut, was passiert. Ich teste praktisch jeden einzelnen Programmierschritt auf "was wäre wenn". Dieses Vorgehen verlangsamt den gesamten Programmierungsprozess erheblich. Muss aber sein, um logische Fehler möglichst frühzeitig zu entdecken. Ich habe mir dies schon sehr früh angewöhnt, als ich vor über 20 Jahren (auf dem C64 + C128; beide hab ich noch!) mit BASIC anfing und logische Fehler erst dann zu suchen anfing, als das Programm fertig war und nicht die gewünschten Ergebnisse lieferte. Ich erinnere mich, dass ich meine allerersten Programme manchmal ganz von vorne anfangen musste, weil ich den Fehler nicht finden konnte. Das war doppelte Arbeit und muss nicht sein.

Nun, ich habe gestern MySql-Fehlermeldungen gesucht aber #1062 nicht gefunden. Darum dankeschön dedlfix für die Info! Den Rest baue ich mir wieder zusammen.
Vielleicht können wir uns auch mal per email austauschen. Dann kann ich Dir ganze scripte schicken oder Probleme ansprechen, die nicht so für die Öffentlichkeit gedacht sind.

Gruss
Thorsten

[treziman]

Hallo,

ich habe ein neues Problem. Folgendes:

Datenbank: kunden
Tabelle:   test

Spalten:  id     userid      nickname      passwort    status     email

Inhalt:    7                 Thorsten

userid, nickname und email = UNIQUE

Gemäss Anleitung von dedlfix in einem vorherigen posting, wird 'Thorsten' versuchsweise eingetragen um zu testen, ob es diesen Namen schonmal in der DB gibt. Die folgende Abfrage und Auswertung im script mittels:
...
if (mysql_errno() == 0)...
...
läuft prima.

Denselben Vorgang, also Testeintrag, Abfrage und Auswertung, muss ich mit der email wiederholen. Und da hakt es. Nach dem Testeintrag der email müsste die Tabelle so aussehen:

Spalten:  id     userid      nickname      passwort    status     email

Inhalt:    7                 Thorsten

8                                                     Emailadresse

Tuts aber nicht. Ich erhalte den Fehlercode #1062, obwohl es die Email in der Tabelle definitiv nicht gibt!
Allerdings kann ich die Email in dieselbe Zeile schreiben, in der bereits der Nickname steht und auch in eine leere Tabelle. Nur in eine neue Zeile, wenn in der vorherigen etwas steht, klappts nicht.
Meine Frage nun: ist das richtig so oder wieder ein lokales Problem auf meinem System?
Ich habe die Kollation auf 'utf8_general_ci' gesetzt. Hat das evtl. damit zutun?

Gruss
Thorsten

[dedlfix]

Hi!

Spalten:  id     userid      nickname      passwort    status     email
Inhalt:    7                 Thorsten
           8                                                     Emailadresse
Tuts aber nicht. Ich erhalte den Fehlercode #1062, obwohl es die Email in der Tabelle definitiv nicht gibt!

Wie lautet der Meldungstext, auf welche Spalte bezieht sich der Fehler? Eine Unique-Constraint-Verletzung bekommst du auch bei Leerstrings. Ich nehme an, du hast noch weitere Datensätze und es kommt zu doppelten Leerstrings. Wenn das der Fall sein kann, solltest du stattdessen mit NULL arbeiten.

Ich habe die Kollation auf 'utf8_general_ci' gesetzt. Hat das evtl. damit zutun?

Nur insofern, als dass bei einer _ci-Kollation beispielsweise foo und FOO als gleich angesehen werden, bei _bin hingegen nicht. Da bei

Lo!

[treziman]

Hallo,

ich glaube, ich habs. Leider bin ich gerade nicht an meinem eigenen Pc, um es zu testen, aber Montag wieder.

Wegen der Leerstrings hatte ich auch schon überlegt. Es werden aber keine übergeben und die zu übergebenden Variablen kommen auch korrekt an. Ich erhalte diese Fehlermeldung erst, wenn ich die zweite Zeile schreiben will (email eintragen). Sehe ich mir meine Tabelle nochmal an fällt auf, dass die Spalte 'userid' leer ist. userid, nickname und email sind vom Typ UNIQUE! Heisst: wenn ich die email eintragen will, führt das wahrscheinlich nicht zum Fehler, aber 'userid' bleibt in beiden Zeilen leer - wären also doppelt. NULL würde das wahrscheinlich auch nicht ändern, oder?

Also leere Felder vom UNIQUE dürfen wahrscheinlich nicht sein? Teste ich sofort Montag.

Spalten:  id     userid      nickname      passwort    status     email
Inhalt:    7                 Thorsten
           8                                                    Emailadresse

Im fertigen script würde ich diese Fehlermeldung nicht bekommen, weil nach jedem Testeintrag und KEINER Fehlermeldung der Eintrag sofort wieder gelöscht wird. Der Grund ist der Registrierungsvorgang. Erst wenn dieser komplett abgeschlossen ist, werden die Daten in die DB geschrieben. Dann aber alle zusammen.

Danke dedlfix für den Denkanstoss 'Leerstring'.
Gruss
Thorsten

[dedlfix]

Hi!

aber 'userid' bleibt in beiden Zeilen leer - wären also doppelt. NULL würde das wahrscheinlich auch nicht ändern, oder?

Doch. NULL ist eine Sonderform. Wann immer ein NULL im Spiel ist, ist das Ergebnis einer Operation auch NULL. Im boolschen Kontext evaluiert das immer zu false, womit als Ergebnis eines Vergleichs von NULL mit NULL immer false rauskommt. Man könnte das nun so sehen, dass die Unique-Prüfung feststellt, dass das neu einzutragende NULL verglichen mit den bereits bestehenden NULLs nicht gleich ist und damit einen anderen Wert darstellt. In Wirklichkeit wird es wohl eher so sein, dass die NULL-Werte gleich gar nicht in den Index aufgenommen werden und somit auch nicht beachtet werden.

Im fertigen script würde ich diese Fehlermeldung nicht bekommen, weil nach jedem Testeintrag und KEINER Fehlermeldung der Eintrag sofort wieder gelöscht wird.

Mag sein, aber beim Entwickeln muss man gelegentlich zusätzlichen Code schreiben, um seine eigenen Denk- und Programmierfehler zu finden. Du musst also erst einmal herausfinden, ob deine Überlegungen und der daraus resultierende Code für alle vorkommenden Anwendungsfälle korrekt sind und das gelegentlich mit der Ausgabe von Fehlermeldungen überprüfen. Der Code dazu kann im Endprodukt wieder gelöscht werden.

Lo!

[treziman]

Mag sein, aber beim Entwickeln muss man gelegentlich zusätzlichen Code schreiben, um seine eigenen Denk- und Programmierfehler zu finden. Du musst also erst einmal herausfinden, ob deine Überlegungen und der daraus resultierende Code für alle vorkommenden Anwendungsfälle korrekt sind und das gelegentlich mit der Ausgabe von Fehlermeldungen überprüfen. Der Code dazu kann im Endprodukt wieder gelöscht werden.

Stimmt. Darum bin ich wohl auch auf diesen Fehler gestossen.

Nochmal zu NULL: wenn ich irgendwann mal einen Eintrag löschen will, wie muss man das formulieren?
Mit mysql_query...values('')...? Würde vielleicht automatisch mit NULL gefüllt? Oder direkt mit ...values('NULL')...?

Melde mich morgen wieder.
Gruss
Thorsten

[dedlfix]

Hi!

Nochmal zu NULL: wenn ich irgendwann mal einen Eintrag löschen will, wie muss man das formulieren?

Bei WHERE primärschlüsselfeld=... brauchst du keinen Inhalt zu kennen. Genau da gibt es unter anderem das Primärschlüsselfeld.

Mit mysql_query...values('')...? Würde vielleicht automatisch mit NULL gefüllt? Oder direkt mit ...values('NULL')...?

NULL ist ein Schlüsselwort, wird also ohne Anführungszeichen notiert, sonst ist es nur ein String.

Jedes Feld hat einen Default-Wert, der beim Einfügen verwendet wird, wenn das betreffende Feld nicht im INSERT-Statement aufgeführt wurde. Bei Feldern, die NULL erlauben ist der Default-Wert des Default-Wertes NULL. Soll heißen: beim Hinzufügen eines Feldes zur Tabelle kann man einen Defaultwert festlegen. Wenn du das nicht machst, ist es bei NULL-erlaubten Feldern NULL ansonsten ein Leerstring.

Lo!

[treziman]

Hallo,

habs gerade getestet - das wars tatsächlich.

Tabelle: test

id       userid      nickname      passwort    status    email
8        xxxxxx      yyyyyyyy                            aaaaaaaa
9                                                        neuemail

Wenn also in der ersten Zeile die UNIQUE-Felder userid, nickname und email einen Inhalt haben, kann ich in die zweite Zeile 'neuemail' eintragen. Zeile 3 gibts wieder die Fehlermeldung, was ja korrekt ist.
Ich werde erstmal ohne NULL arbeiten. Die userid wird vom script erzeugt und wird ähnlich aussehen wie eine session-ID, hat aber einen anderen Sinn als der Nickname. Nickname und email sind Pflichtangaben. Somit werden diese 3 Felder niemals leer sein.

Nochmal dankeschön dedlfix!

Gruss
Thorsten

[dedlfix]

Hi!

Defaultmässig ist kein Passwort angelegt und der User ist 'ROOT'. Nach meinem Infostand ist beides schlecht für den Betrieb auf einer Homepage, und so habe ich ein Passwort angelegt und den User auf 'kunden' geändert.

Das macht es auch nicht besser, denn wenn du nur den Superuser umbenennst, ändert sich an der Macht des Users nichts. Lass den root bestehen und gib ihm nur ein Passwort - je kryptischer desto besser. Du brauchst den User für Administrationszwecke. Dann leg einen neuen an und gib ihm keine globalen Rechte sondern nur die benötigten für die jeweilige(n) Datenbank(en).

Ich habe XAMPPLITE installiert und wenn ich nun im Control Panel hinter MySql auf 'Admin' klicke, bekomme ich folgende Fehlermeldung:

Welchen MySQL-Server kontaktiert dieser, den mitgelieferten oder deinen produktiven?

#1045 - Access denied for user 'root'@'localhost' (using password: NO)

Du siehst hier, dass nicht nur der Username sondern auch der Ursprungshost der Anfrage von Bedeutung ist. Das heißt, MySQL nimmt nicht nur zwei Anmeldekriterien (User und Passwort) sondern drei (User, Host des Requests, Passwort).

In der config.inc.php steht defaultmässig:
Habe ich geändert auf:

Das will man in der Regel auf dem komplett selbst verwalteten Server nicht, weil man mit dem PMA üblicherweise den gesamten MySQL-Server administrieren will. Lediglich das Root-Passwort sollte angepasst werden.

Egal was ich auch ändere, ich bekomme immer die oben zitierte Fehlermeldung. Nach jeder Änderung habe ich im Control Panel den Service MySql gestoppt und neu gestartet.

Bei Änderungen der Rechte muss nicht der gesamte MySQL-Server neu gestertet werden, es reicht auch ein FLUSH PRIVILEGES.

Ich habe das Gefühl, als ob diese config.inc.php gar nicht abgearbeitet wird, obwohl ich, wie gesagt, immer wieder neu starte.

Das bekommt man raus, indem man einen Syntaxfehler einbaut, über den das PHP stolpern muss.

Kurz: ich kann mich nicht mehr unter phpmyadmin einloggen und die DB bearbeiten. Was mache ich falsch?

Setz das Root-Passwort auf einen definierten Wert, so dass du wieder Zugriff hast. Kontrolliere, dass du den richtigen Server ansprichst, bring den PMA mit dem Root-User zum laufen. Leg eine eingeschränkte Kennung für deine Anwendung an. Als Hostangabe reicht localhost, wenn du nur mit dem auf der selben Maschine befindlichen PMA zugreifen willst und auch die Anwendung auf dem selben Rechner läuft.

Lo!