So, nun würde mich mal was interessieren.

Ich nutze das Parameter-Binding für Prepared Statements i.d.R. immer mit bindParam():

Für mein Verständnis reagiert PDOStatement jetzt auf die übergebenen Datentypen, denn würde er bspw. auch $myId als String übergeben bekommen, müsste er den gefilterten Wert ja z.B. noch in Quotes setzen, was aber für MySQL nicht korrekt wäre. Abgesehen davon, daß die Filterung ja auch Datentyp bedingt sein sollte.

Nun gibt es die execute()-Methode, mit der man die Values auch per Array übergeben kann. Die aber übergibt ja erstmal alle Values zunächst als PARAM_STR, also auch die ID als String.
Jetzt frage ich mich, wie zuverlässig das dann ist? Erkennt er trotzdem, daß es sich bei $myId um einen Ganzzahlenwert handelt und behandelt den dann intern doch wieder als Integer?
Wenn ja, woher will er wissen, daß nicht auch ein Integer-Wert in eine VARCHAR-Spalte geschriebenen werden könnte/sollte?!

Vielleicht kann mir dazu jemand mal den Horizont erweitern?
Danke!

(26.03.2015, 13:01)Arne Drews schrieb: So, nun würde mich mal was interessieren.

Ich nutze das Parameter-Binding für Prepared Statements i.d.R. immer mit bindParam():

PHP-Code:

$pdoStatement = $pdoInstance->prepare( "SELECT `column` FROM `table` WHERE `sometext`=? and `id`=?" );
$pdoStatement->bindParam( 1, $sometext, PDO::PARAM_STR );
$dpoStatement->bindParam( 2, $myId, PDO::PARAM_INT );

$pdoStatement->execute();
// usw... 


Für mein Verständnis reagiert PDOStatement jetzt auf die übergebenen Datentypen, denn würde er bspw. auch $myId als String übergeben bekommen, müsste er den gefilterten Wert ja z.B. noch in Quotes setzen, was aber für MySQL nicht korrekt wäre. Abgesehen davon, daß die Filterung ja auch Datentyp bedingt sein sollte.

Nun gibt es die execute()-Methode, mit der man die Values auch per Array übergeben kann. Die aber übergibt ja erstmal alle Values zunächst als PARAM_STR, also auch die ID als String.
Jetzt frage ich mich, wie zuverlässig das dann ist? Erkennt er trotzdem, daß es sich bei $myId um einen Ganzzahlenwert handelt und behandelt den dann intern doch wieder als Integer?
Wenn ja, woher will er wissen, daß nicht auch ein Integer-Wert in eine VARCHAR-Spalte geschriebenen werden könnte/sollte?!

Vielleicht kann mir dazu jemand mal den Horizont erweitern?
Danke!

Da verlässt sich meiner Erfahrung nach PDO ganz auf die Datenbank - und MySQL ist intelligent genug eine automatische Typ-Konvertierung vorzunehmen - also eine Zahl in Quotes wird immer als Zahl gewertet, wenn es sich um eine Zahlen-Typ-Spalte handelt. Meiner Erfahrung nach geht dabei nichts kaputt....

ich hab anfangs mysql_ und danach mysqli_ per Hand programmiert und öfters mal auf Zahlenparameter aus Formular-Eingaben in Quotes übergeben, teils als Test wegens SQL-Injection, teils aus Bequemlichkeit - und solang Zahlen eingegeben wurden, hat das immer funktioniert. Natürlich lernt man dazu und macht das irgendwann besser, indem Eingaben richtig validiert werden usw...

Erst als ich PDO bzw das darauf aufsattelnde PHPar (active record) benutzt habe, wurde das anders, weil prepared Statements zum Einsatz kamen - und hier PHPar automatisch die benötigten Abfragen generiert und dafür prepared Statements verwendet und die richtigen Formate angibt.

Ergänzung - ich würd es aber nicht machen bei "Datenbanken", die empfindlicher reagieren. Zumindest MS Access und der erwachsene MS-SQL Server sind nicht so großzügig. Ich musste feststellen, dass beim Testbetrieb (es wurde die Umstellung auf MSSQL erwogen), die Abfragen mit Zahlen in Quotes plötzlich nicht mehr funktionierten - Fehleranalyse verwies exakt auf die Zahl-Strings - und habe da dann einige Zeit investiert, um die Syntax zu bereinigen.

Hallo, ich wollte mir das heute Abend nochmal genauer ansehen, aber ich kann ja jetzt schonmal versuchen meine Gedanken mitzuteilen.

Wie schon im anderen Thread angedeutet:
Ich denke MySQL ist völlig egal, ob da ein Int oder String reinkommt. Die Query wird ja in C++ aufgelöst und da kommt dann dessen Type-Konvertierung mit ins Spiel.

Meine Vermutung war, dass bindParam() bzw. bindValue() beim Emulieren der Statements helfen indem, wie du schon meintest, entsprechend im Query die Quotes gesetzt und der String escaped werden.
Über den Haufen geworfen wird es dadurch, dass es ja auch mit falscher Typ-Angabe beim binden zu keinerlei Problem kommt.

Also was diese beiden Funktionen betrifft bin ich absolut ratlos. Allerdings ist PDO ja auch für mehrere DB-Treiber gedacht... who knows was bei den anderen so alles geht..


Habe den Post wiedergefunden, aus dem ich ein bisschen was zur Funktionsweise mitgekriegt habe, vielleicht könnt ihr mehr draus entnehmen. http://guilhembichot.blogspot.de/2014/05/re-factoring-some-internals-of-prepared.html

eagle275 schrieb:Ich musste feststellen, dass beim Testbetrieb (es wurde die Umstellung auf MSSQL erwogen), die Abfragen mit Zahlen in Quotes plötzlich nicht mehr funktionierten - Fehleranalyse verwies exakt auf die Zahl-Strings - und habe da dann einige Zeit investiert, um die Syntax zu bereinigen.

Genau das hatte ich von MySQL auch erwartet, zumindest war ich immer der Meinung, daß er das auch bemängeln würde.
Ok, aber für mich selber bleibe ich lieber bei der Datentyp-Angabe.

Danke!

(26.03.2015, 14:31)Arne Drews schrieb:

eagle275 schrieb:Ich musste feststellen, dass beim Testbetrieb (es wurde die Umstellung auf MSSQL erwogen), die Abfragen mit Zahlen in Quotes plötzlich nicht mehr funktionierten - Fehleranalyse verwies exakt auf die Zahl-Strings - und habe da dann einige Zeit investiert, um die Syntax zu bereinigen.

Genau das hatte ich von MySQL auch erwartet, zumindest war ich immer der Meinung, daß er das auch bemängeln würde.
Ok, aber für mich selber bleibe ich lieber bei der Datentyp-Angabe.

Danke!

tja - was willste machen, PHP ist nunmal notorisch typ-schwach ^^