Hallo Tagwächter, hallo Rolf b, hallo dedlfix, hallo zusammen, :-)
danke nochmal für Euer Feedback! Den Großteil davon habe ich jetzt (hoffentlich) eingearbeitet. Ich hoffe, dass ich nichts vergessen oder übersehen habe. Sagt sonst bitte einfach Bescheid. Ich habe jetzt folgendes geändert:
- error, errno, affected_rows und num_rows hinzugefügt (Tagwächter)
- Definition API (dedlfix)
- Definition/Links unbekannte Begriffe (dedlfix)
- Auswahl API nach Anwendungsfall => Auswahl API nach persönlicher Vorliebe (Rolf b, dedlfix)
- Falsche Verwendung mysqli_connect_error()/mysqli_connect_errno() (Rolf b)
- MySQL wurde aus Sicherheitsgründen entfernt streichen (Rolf b, dedlfix)
- Kein Kontextwechsel bei PDO (Rolf b, dedlfix)
- Änderung am Produktivsystem als Empfehlung (dedlfix)
- "oben, unten, links, rechts", sinnvolle Linknamen (dedlfix)
- Hinweis zu erlaubten Zeichensätzen (dedlfix)
- Nur ein try...catch-Block (dedlfix)
- Keine Fehlerüberprüfung bei mysql_real_escape_string (dedlfix)
- Keine Variable für Query, direkte Anwendung von escape_string (dedlfix)
@Rolf b, Du schriebst:
Und um zu prüfen, ob
$link = mysqli_connect(...)
fehlschlug, soll manif (!$link)
testen. (siehe Beispiel hier)
Ich bin mir da etwas unschlüssig. Wenn ich das Manual richtig verstehe, müssten doch diese drei Varianten auf's gleiche hinauslaufen?
$link = mysqli_connect(...);
if (!$link) { /* ... */ }
if (mysqli_connect_error()) { /* ... */ }
if (mysqli_connect_errno()) { /* ... */ }
Oder irre ich mich da? Wenn nicht, gibt es eine Variante, die zu bevorzugen ist? Das einzige was ich gelesen habe ist, dass $link->connect_error
erst ab PHP 5.3 funktioniert und man stattdessen die prozedurale Variante nehmen muss. Das ist aber eine Anmerkung, die man sich hier meiner Meinung nach sparen kann. Oder was meint ihr?
Was sonst noch offen wäre ist die Fehlerbehandlung, da bin ich mir weiterhin unschlüssig, was die beste Variante ist. Man könnte
- es so lassen wie es ist, ein Anfängertutorial mit konkretem Anwendungsfall erstellen und darauf verlinken
- einen konkreten Anwendungsfall in diesem Artikel unterbringen
- die Fehlerbehandlung in diesem Artikel irgendwie sinnvoll verschachteln oder
- die Kommentare innerhalb der Fehlerbehandlung ausbauen und sonst nichts ändern
Sicherlich gibt es auch noch mehr Möglichkeiten. Was meint ihr dazu?
Weiteres Feedback ist natürlich weiterhin erwünscht :-)
Gruß
Dennis