nicht angemeldet
Die Fehlermeldung kommt ja wohl ganz offenkundig aus dem execute():
"You have an error in your SQL syntax; check the manual that corresponds to your MySQL server version for the right syntax to use near 'alter,sex,teilnahme,email,datum) VALUES ('1004','anonym','a','a','a','a','a','2'' at line 1 at zum_ausflippen.pl line 37."Ja, stimmt, denn hier sind die Werte eingefügt. Das heißt, dass Perl in dem Fall nicht in der Lage ist, die von der MySQL-API angebotenen Funktionen für Prepared Statements zu nutzen und sie stattdessen selbst simuliert.
Wenn wir schon mal präzise sein wollen, dann halten wir fest, dass Prepared Statements vom DBI keinesfalls simuliert werden, sondern lediglich SQL-Statements mit Platzhaltern bereitgehalten werden. Irgendwelche der von Dir an anderer Stelle zitierten Vorteile von Prepared Statements sind nicht erkennbar. Oder anders formuliert: Es geht nicht um Prepared Statements.
Dabei kommt aber kein PREPARE-Statement zur Anwendung.
Klar, es geht nicht um prepared statements, wie von Dir behauptet, vgl. auch http://search.cpan.org/~timb/DBI-1.53/DBI.pmWelche Stelle dort genau meinst du? Das Dokument ist doch recht umfangreich und nicht alles passt auf das Thema.
Such mal nach "Drivers for engines without the concept of preparing a statement will typically just store the statement in the returned handle and process it when $sth->execute is called." - so ein Driver liegt vor.
O.K. es war nicht das versandte Statement. Trotzdem war die von dir bemängelte Parameter-Anzahl irrelevant.
War ein Anfangsverdacht, was wissen wir wie DBI das SQL-Statement zusammenbastelt?
MySQL gibt bei Syntax-Fehlern den Teil vom Auftreten des Fehlers und die folgenden 80 Zeichen aus. Der Fehler ist also am Anfang des Zitats zu suchen, und der Rest ist für diesen Fehler belanglos.
Schon klar, wg. "alter" hätte man Bescheid wissen können.
Somit sollte nach einem bind_param() - wie von uns angeregt - dieses hier im Forum für Analysezwecke angegeben werden.
Das ist im Allgemeinenen dann richtig, wenn man sein Statement selbst zusammenbaut. Wenn dabei vertrauenswürdige Komponenten im Spiel sind, wie DBI oder die Prepared-Statement-Mechanismen oder -Nachbildungen anderer Systeme oder APIs, ist das nicht mehr erforderlich und manchmal gänzlich unmöglich.
Stichwort "pass-thru mode", d.h. die DBI-Verpackung ist dankenswerterweise recht dünn. Davon unabhängig, sind Probleme hartnäckiger Art, dann _muss_ man in die Logs des Datenservers bzw. mit einem "Profiler-Tool" kommen. Und zwar um das SQL-Statement zu packen zu kriegen.
Gustl