Ich glaube auch der Vergleich hinkt: Mysql rangiert in etwa im Bereich VHS, statt DVD.

__________________
github | http://dnaber.de

ein grund für mich was altes zu verwenden ist, das ich mysql noch aus meiner programmierzeit vor über 10 jahren kann, aber das neue müsste ich neu lernen. du hast gefragt

somit würde ich nur auf das neue wechseln, wenn es wirklich einen technischen vorteil bietet, warum sollte ich es sonst tun, wenn ich das alte noch kann und nicht lernen muss?

alt ist nicht grundsätzlich schlecht

ich brauch einenn film auch nicht in 1080p sehen, wenn kein unterschied zu 720p erkennbar ist, nur weil es neuer, weiterentwickelt oder wie auch immer ist.

das ist nur meine grundsätzliche meinung zu dem thema, das soll nicht heißen das ich mich mysqli verweigere. vielleicht stelle ich ja noch fest, welche vorteile mysqli mir bietet, dann steige ich auch gern um.

wenigstens nicht im bereich stummfilm. nochmal glück gehabt. puuh

gruß
knuff

explanator hat in #2 eine Seite verlinkt, die das erklärt, aber ruf ansonsten einfach mal eine Dokuseite deiner Wahl zur alten mysql-Erweiterung auf. Etwa:

- PHP: mysql_query - Manual

Wenn du dein Error-Reporting aufgedreht hast, bekommst du ab PHP 5.5 auch direkt dort deprecated-Warnungen.

mysqli wird laut Doku ab MySQL 4.1.3 empfohlen. Die Version ist steinalt: MySQL - Wikipedia, the free encyclopedia

- PHP: Overview - Manual

Auf phpforum.de gibt es seit 2011 eine Standardantwort dazu. Und wir waren dort sehr spät mit der.

- Standardantwort zu veraltete mysql-Extension - PHP Forum: phpforum.de

Anders gesagt: Die PHP-Community schlägt sich seit etlichen Jahren damit rum, Leuten mitzuteilen, dass die Erweiterung veraltet ist. Entsprechende Hinweise lese zum Beispiel ich gefühlte 10-mal am Tag. Und wenn die Extension dann wirklich mal entfernt wird, werden noch mal endlos Threads kommen, in denen sich Leute darüber beklagen, dass Code nicht mehr läuft und dass man das mal vorher hätte mitteilen sollen.

Wir denken uns das jedenfalls nicht aus.

Ich kann dir nicht sagen, warum das geändert wurde. Wenn ich raten sollte: Das ist eine Angleichung an Destruktoren (__destruct). Das ist zumindest auch schon seit +/- 10 Jahren so (seit PHP 5). Die Doku dazu habe ich ja schon verlinkt. Die alten Konstruktoren funktionieren aus Gründen der Abwärtskompatibilität noch (sind meines Wissens auch nicht als deprecated markiert), aber sind seit Jahren völlig unüblich. Ich sage es nur.

Auf welcher Datenbankverbindung operiert denn ein Aufruf wie mysql_real_escape_string($pagename)? – Auf der zuletzt geöffneten.

Ist das diejenige, die du mit der Instanz deiner Datenbank-Klasse verwaltest, der du die escapeten Daten übergeben willst? – Mehr oder weniger reine Glückssache.

Ist es wichtig, dass der Escaping-Befehl mit der richtigen DB-Verbindung arbeitet? – Das ist schwierig zu erklären, aber die Antwort ist eindeutig: Ja. Escaping kann nur dann funktionieren, wenn spezifische Eigenschaften der Verbindung bekannt sind. Ansonsten triffst du im aufrufenden Code Entscheidungen auf Basis von Vermutungen. Deshalb taugt etwa auch addslashes nicht als Escaping-Funktion für DB-Queries. Beispiel: Chris Shiflett ▪ addslashes() Versus mysql_real_escape_string()

Das ist ein Fehler der Marke „vermutlich wird nie was passieren“. Falsch ist es aber dennoch.

Das kleine l in runSQlQuery. Edit: Wobei, eigentlich stört mich das große Q. Na ja, Geschmackssache.

Also wir fasssen zusammen, ein handfestes Argument ist für dich, "ich will das einsetzen was ich vor 10 Jahren gelernt habe und ich möchte nichts neues lernen"?
Ok, mal eine neue Definition von "handfest"

Du musst aber auch die Links lesen, die man dir zeigt, ich habe dir eine Liste der technischen Vorteile gezeigt.
Aber mermshaus hat dir es dir nun auch ausführlich erklärt.