nicht angemeldet
Hello,
Geht es bei bind_param() nicht nur um das Escaping in der Schnittstelle?
Nein, Das ist der Vorteil an Prepared Statements, dass da nichts maskiert werden muss. Die Query geht ja schon mit dem Prepare zum Server. Die Werte kommen später mit dem Execute. Man übergibt mit dem Binding die Roh-Werte und den Rest macht die Server-API. Darauf hat man keinen Einfluss und muss darauf vertrauen, dass das richtig und problemlos abläuft.
Ok, dann gibt es also nicht nur in PHP was neues (PDO), sondern das setz auch auf einer anderen Schnittstelle auf? *Ups*, da ist mir jetzt wirklich allerhand durchgeflutscht in dem einen Jahr als "Pastor".
Das muss zum Spaltentyp passen, damit die SQL-Operation wunschgemäß und abgesichert stattfinden kann.
Nee, wer sagt denn, dass der Wert am Ende irgendwann in einer Spalte landen soll? Der Platzhalter steht irgendwo im SQL-Statement, und da kann er auch in einem komplexen Ausdruck stehen, der noch dreimal typgewandelt werden muss, oder gar nicht in einer Spalte landet oder mit dem Inhalt einer solchen verglichen wird.
Dann hatte ich davon eine vollkommen falsche Vorstellung. Ich hatte angenommen, dass hier nur PHP renoviert worden war, um mit unterschiedlichen Servern reden zu können und das PHP-APP-Programmierer-seits konsequent objektorientiert zu tun.
Ehrlich gesagt, erschließt sich mir nicht, welche Auswirkungen die Typangabe konkret hat. In meinen Versuchen mit String und Integer war alles gemixt möglich, sowohl beim SELECT in einem WHERE als auch beim INSERT (jeweils direkt die Felder angesprochen).
Was passiert denn, wenn man mit den Werten rechnet oder kleiner/größer-Vergleiche anstellt. Da müssten sich Strings doch anders verhalten, als Nums.
* '1119' < '9'
aber
* 1119 > 9
Hier greifen wohl PHPs und MySQLs Typumwandlung zusammen ins Geschehen ein. Ich nehme immer s solange es funktioniert. Mich würde mal mehr interessieren, was das konkrete Szenario war wo das i notwendig wurde, und welche Fehlermeldung genau kam.
Naja, "Martin_Online" grooves sich inzwischen ja hoch und arbeitet mit. Da ist die Chance gut, dass wir alle noch 'was davon haben. Ich hoffe, dass er weiß, wie wertvoll die eigene Dokumentation der neuen Erkenntnisse für ihn später noch werden kann :-)
Ich hatte ja gestern auch einen schlechten "->execute()"-Tag, und versuche nun zu ergründen (und mir zu merken), wo überall die Unterschiede zwischen mysqli-prepared Statements und PDO liegen.
##---
Aber z.Zt. knabber ich noch am Signalling und der Überarbeitung meiner Triggers.
Ich habe noch nicht ganz begriffen, wie aus
signal sqlstate '45000' set message_text = msg;
dann später
/* SQL Fehler (1644): -- usw.
wird, also welcher SQL-State in welche Fehlernummer übersetzt wird.
http://dev.mysql.com/doc/refman/5.5/en/error-messages-server.html
Isr wahrscheinlich ganz einfach, wenn man weiß, wie es zusammenhängt :-O
Liebe Grüße aus dem schönen Oberharz
Tom vom Berg
Der Martin