Meowsalot: Kein Insert in meine MySQL Datenbank

Hallo alle,

könnt ihr mir sagen wo hier der Fehler liegt? Das Script macht kein Insert, bringt aber auch keine Fehlermeldung

 if ($stmt = $mysqli->prepare("INSERT INTO user_anwesenheit_tage (uat_userid, uat_mo, uat_di, uat_mi, uat_do, uat_fr, uat_sa, uat_so)  
                                    VALUES (?, ?, ?, ?, ?, ?, ?, ?)"))
{
    $stmt->bind_param("ssssssss",
                      $user, $_POST["uat_mo"], $_POST["uat_di"], $_POST["uat_mi"], 
                      $_POST["uat_do"], $_POST["uat_fr"], $_POST["uat_sa"], $_POST["uat_so"]);          
    $stmt->execute();
}
else {
    echo $mysqli -> error;
}

Die HTML Felder sehen so aus

<label for="uat_mo">Montag</label>
        <input name="uat_mo" type="checkbox" name="uat_mo" id="uat_mo" style="width: 2%" value="1">

Bis bald! Meowsalot (Bernd)

Edit Rolf B: Code formatiert

  1. Tach!

    könnt ihr mir sagen wo hier der Fehler liegt? Das Script macht kein Insert, bringt aber auch keine Fehlermeldung

    Mir fällt da auch nichts auf.

     if($stmt = $mysqli->prepare("INSERT INTO user_anwesenheit_tage (uat_userid, uat_mo, uat_di, uat_mi, uat_do, uat_fr, uat_sa, uat_so)  
                                        VALUES (?, ?, ?, ?, ?, ?, ?, ?)"))
            {
                $stmt->bind_param("ssssssss", $user, $_POST["uat_mo"], $_POST["uat_di"], $_POST["uat_mi"], $_POST["uat_do"], $_POST["uat_fr"], $_POST["uat_sa"], $_POST["uat_so"]);          
                $stmt->execute();
                }
                else {
                    echo $mysqli -> error;
                }
    

    Aber sowohl bind_param() als auch execute() liefern einen booleschen Wert als Ergebnis. Prüf die beiden mal, ob die true sind. Denn wenn die false sind, wird zwar $mysqli->error gefüllt, aber das fragst du dann nicht mehr ab. Und einen Folgefehler seitens PHP, der zu einer Meldung führen könnte, kann da auch nicht auftreten.

    dedlfix.

    1. Hallo dedlfix,

      ich habe nochmals geschaut und damit ist mir folgendes aufgefallen. Wenn alle Checkbox angeklickt sind, dann bekomme ich ein Insert. Es kann doch nicht sein, dass ich immer alle ausfüllen muss?

      Bis bald!
      Meowsalot (Bernd)

      1. Hallo Meowsalot,

        wenn ich es wie folgt mache, dann kann ich auch leere Einträge speichern

        if ($_POST["montag"] != "") {
                $Montag = $_POST["montag"];
            } else {
                $Montag = "";
            }
        

        Aber muss ich es umständlich machen? Liegt dieses an den Checkboxen?

        Bis bald!
        Meowsalot (Bernd)

        1. Guck Dir doch an was übertragen wird: Wenn eine checkbox name und value hat wird der value übertragen wenn sie ausgewählt wurde. Alles klar ?

          😉

          1. Hallo pl,

            a) wie ich mir es ansehen?
            b) warum kann ich dann nur ein Insert machen wenn alle angeklickt sind?

            Bis bald! Meowsalot (Bernd)

            1. Hallo pl,

              a) wie ich mir es ansehen?

              Entwicklerkonsole. Wenn method nicht POST ist, siehst Du das auch in der Adresszeile. Am Besten Du baust Dir das Formular mal nach nur um das alles mal in Ruhe testen zu können: nur <form> ohne action ohne enctype ohne method ~Attribute.

              Tipp: Bau da noch einen Link ein womit Du die Seite ohne Parameter reloaden kannst.

              Spielend lernen 😉

      2. Tach!

        ich habe nochmals geschaut und damit ist mir folgendes aufgefallen. Wenn alle Checkbox angeklickt sind, dann bekomme ich ein Insert. Es kann doch nicht sein, dass ich immer alle ausfüllen muss?

        Ah, Checkboxen, gutes Stichwort. Generell, wenn irgendwas nicht so läuft wie erwartet, empfiehlt sich Debugging, wenn man die Ursache nicht allein durch Code-Anschauen findet. Das ist keine beliebte Tätigkeit, aber eine meist recht zielführende. Deswegen kann ich es nicht oft genug betonen, dass man sich diesbezüglich zumindest Grundfertigkeiten aneignet, und das recht zeitig, wenn man mit dem Programmieren anfängt.

        Wenn das Insert nicht klappt, dann kann man sich mal anschauen, was für Werte man da übergibt, also mal ein var_dump($_POST) in deinem Fall. Damit könntest du sehen, dass für die nicht angehakten Checkboxen Einträge fehlen. In der Folge ist PHP nicht in der Lage, aus den fehlenden Einträgen etwas rauszulesen, um es dem Statement übergeben zu können. Stattdessen wird es wohl null beim Lesevorgang liefern und dann beschwert sich das execute(), weil die Datenbankfelder kein NULL annehmen dürfen, so zumindest meine Vermutung. Das Gejammer des execute() überhörst du aber, weil du nicht auswertest, dass es false zurückliefert und daraufhin auch nicht den Fehlermeldungstext aus der Eigenschaft $mysqli->error abfragst.

        Warum aber sind die Einträge nicht vorhanden? Dazu befragt man am besten die Quelle, also den Browser, und da ist das Mittel der Wahl üblicherweise seine eingebauten Entwicklertools. Im Netzwerk-Tab kann man sehen, was er auf die Reise schickt, und auch, dass er nichts sendet, wenn die Checkbox nicht angehakt ist. Und das ist so definiert. Nicht gesetzte Checkboxen gehören nicht zu den erfolgreichen Eingabeelementen und werden deshalb ignoriert. Nur wenn sie ausgewählt ist, wird der Inhalt von name und value (oder on, wenn nicht vorhanden) der Checkbox übertragen.

        Ein alter Trick ist, vor die Checkbox ein <input type="hidden"> mit dem Wert für eine nicht angehakte Checkbox im value zu notieren und dafür auch denselben name wie die Checkbox zu geben. Im Unausgewählt-Fall wird dieser Hidden-Input-Wert übertragen, wenn ausgewählt jedoch beide. PHP ignoriert aber den ersten Wert vom Hidden-Input und überschreibt ihn mit dem value der Checkbox.

        dedlfix.

        1. Tach!

          Ein alter Trick ist, vor die Checkbox ein <input type="hidden"> mit dem Wert für eine nicht angehakte Checkbox im value zu notieren und dafür auch denselben name wie die Checkbox zu geben. Im Unausgewählt-Fall wird dieser Hidden-Input-Wert übertragen, wenn ausgewählt jedoch beide. PHP ignoriert aber den ersten Wert vom Hidden-Input und überschreibt ihn mit dem value der Checkbox.

          Übel! Weil dieser fragwürdige Trick nur deswegen so funktioniert, weil der Parser in PHP nicht RFC gerecht arbeitet. Es ist eine ganz schlechte Empfehlung es so zu machen!

          MfG

          1. Tach!

            Ein alter Trick ist, vor die Checkbox ein <input type="hidden"> mit dem Wert für eine nicht angehakte Checkbox im value zu notieren und dafür auch denselben name wie die Checkbox zu geben. Im Unausgewählt-Fall wird dieser Hidden-Input-Wert übertragen, wenn ausgewählt jedoch beide. PHP ignoriert aber den ersten Wert vom Hidden-Input und überschreibt ihn mit dem value der Checkbox.

            Übel! Weil dieser fragwürdige Trick nur deswegen so funktioniert, weil der Parser in PHP nicht RFC gerecht arbeitet. Es ist eine ganz schlechte Empfehlung es so zu machen!

            Ist die RFC das einzige Argument zu dieser Empfehlung? Gibt es wenigstens berechtigte Gründe, warum man dieses Verhalten nicht nutzen sollte? Das Formular hat als Ziel lediglich dieses eine PHP-Script und damit keine anderen Ziele, die mit dem doppelten Feld umgehen müssten. Browserseitig irgendwas? Assistive Techniken und Hidden-Inputs? Vermutlich belanglos.

            Man kann natürlich auch im PHP-Script etwas tun. Zum einen wäre das, das $_POST-Array auf die fehlenden Elemente für die nicht gesetzten Checkboxen zu untersuchen und sie bei Nichtvorhandensein mit dem gewünschten Wert (vermutlich 0) nachzutragen. Achtung, Regenschirm aufspannen, an der Stelle kommen einige Aufreger aus allen Wolken gefallen. Warum eigentlich? Nur weil man da das $_POST-Array an seine Bedürfnisse anpasst und das aus irgendeinem Grunde Frevel wäre?

            Ein alternatives Vorgehen ist, sich eine eigene Datenstruktur zu schaffen, am besten wohl ein Array, aber eine Handvoll lose Variablen tut es im Grunde genommen auch. Diese(s) befüllt man mit den vorhandenen Werten aus dem $_POST-Array, oder mit Default-Werten bei Abwesenheit. Danach ignoriert man das $_POST-Array und arbeitet mit den eigenen Daten weiter. Kann man machen, muss man aber nicht. So ein Vorgehen führt in kleinen Scripten nur neue Variablen ein, ohne dass die Vorteile daraus großartig spürbar sind. Mehr Nutzen ergibt sich erst wenn die Angelegenheit größer wird und ein komplexes Programm entstehen soll, bei dem eigenständige Komponenten erstellt werden zum Zwecke des TDD, und um das Chaos der Komplexität organisatorisch in die Schranken zu weisen, sprich: möglichst wenig Abhängigkeiten zu anderen Komponenten und am besten gar keine zu globalen Dingen, wie eben dem $_POST-Array. Eine Komponente ist dann schön übersichtlich, wenn man oben Parameter einfüllt, unten das Ergebnis entgegennimmt, und sie nicht seitwärts auf irgendwelche Dinge zugreift, für deren Anwesenheit man auch noch sorgen muss, dies aber nicht aus der Parameterliste beim Aufruf erkennen kann.

            Das und noch mehr Prinzipien, die zusammengefasst den Namen SOLID bekamen, sind zwar erstrebenswert - je größer die Projekte desto mehr -, und man kann sich ja auch im Kleinen daran orientieren, um es später die großen mit diesbezüglicher Erfahrung anzugehen, doch das muss der Probleminhaber für sich entscheiden. Schönheit kostet auch ihren Preis, vor allem Zeit.

            dedlfix.

            1. Tach!

              Ein alter Trick ist, vor die Checkbox ein <input type="hidden"> mit dem Wert für eine nicht angehakte Checkbox im value zu notieren und dafür auch denselben name wie die Checkbox zu geben. Im Unausgewählt-Fall wird dieser Hidden-Input-Wert übertragen, wenn ausgewählt jedoch beide. PHP ignoriert aber den ersten Wert vom Hidden-Input und überschreibt ihn mit dem value der Checkbox.

              Übel! Weil dieser fragwürdige Trick nur deswegen so funktioniert, weil der Parser in PHP nicht RFC gerecht arbeitet. Es ist eine ganz schlechte Empfehlung es so zu machen!

              Ist die RFC das einzige Argument zu dieser Empfehlung? Gibt es wenigstens berechtigte Gründe, warum man dieses Verhalten nicht nutzen sollte?

              Das Argument ist, daß man das was man als Entwicklerwerkzeug nutzen will zu 100% verstehen sollte. Das heißt daß man eine diesbezügliche Empfehlung nur dann geben kann, wenn man ein solches Verständnis voraussetzen kann.

              Schönen Tach auch.

              1. Tach!

                Ist die RFC das einzige Argument zu dieser Empfehlung? Gibt es wenigstens berechtigte Gründe, warum man dieses Verhalten nicht nutzen sollte?

                Das Argument ist, daß man das was man als Entwicklerwerkzeug nutzen will zu 100% verstehen sollte. Das heißt daß man eine diesbezügliche Empfehlung nur dann geben kann, wenn man ein solches Verständnis voraussetzen kann.

                Wegen des Verständnisses habe ich ja den Trick inklusive seiner Arbeitsweise erklärt. Erklärst du nun auch noch deine Empfehlung so, dass ich dafür Verständnis aufbauen kann?

                100% Verständnis für die Entwicklerwerkzeuge halte ich auch für ein utopisches und unrealistisches Ziel. Wenn das Voraussetzung wäre, könnte heutzutage niemand mehr produktiv arbeiten.

                dedlfix.

          2. Tach!

            Weil dieser fragwürdige Trick nur deswegen so funktioniert, weil der Parser in PHP nicht RFC gerecht arbeitet.

            Nochmal konkret nachgefragt: Welche RFC regelt, wie PHP das Array $_POST/$_GET aufzubauen hat? Oder allgemein formuliert, wo wird geregelt, wie nach dem Parsen des Requests weiter damit zu verfahren ist?

            dedlfix.

            1. Hallo dedlfix,

              ich finde 2 Quellen.

              1. RFC 2388 - obsoleted by RFC7578

              5.5 Ordered fields and duplicated field names
              
                 The relationship of the ordering of fields within a form and the
                 ordering of returned values within "multipart/form-data" is not
                 defined by this specification, nor is the handling of the case where
                 a form has multiple fields with the same name. While HTML-based forms
                 may send back results in the order received, and intermediaries
                 should not reorder the results, there are some systems which might
                 not define a natural order for form fields.
              

              2. RFC 7578

              5.2.  Ordered Fields and Duplicated Field Names
              
                 Form processors given forms with a well-defined ordering SHOULD send
                 back results in order.  (Note that there are some forms that do not
                 define a natural order.)  Intermediaries MUST NOT reorder the
                 results.  Form parts with identical field names MUST NOT be
                 coalesced.
              

              Dein Tipp setzt Verhalten voraus, das sehr wahrscheinlich so von der Netzinfrastruktur erbracht, aber erst durch RFC7578 garantiert wird. Die Chance eines Fehlers mag im Bereich 10⁻⁴ liegen, aber wer kann das einschätzen?

              Ich hatte tatsächlich auch schon meinen Finger auf dem Antwort-Button, um mein Unbehagen zu dieser Idee auszudrücken, konnte es aber nicht begründen. Meine Lösung würde immer serverseitig aussehen, entweder durch Modifikation von $_POST oder beim Übertragen von $_POST in ein Postdata-POPO.

              Danke an PL für den Tipp mit den RFC.

              Rolf

              --
              sumpsi - posui - clusi
              1. Tach!

                Dein Tipp setzt Verhalten voraus, das sehr wahrscheinlich so von der Netzinfrastruktur erbracht, aber erst durch RFC7578 garantiert wird. Die Chance eines Fehlers mag im Bereich 10⁻⁴ liegen, aber wer kann das einschätzen?

                Gibts das auch für den hier vorliegenden Fall mit application/x-www-form-urlencoded?

                Den Trick gibts jedenfalls schon lange, und ich wüsste auch nicht, warum ein Browser das umsortieren wollen würde. Sowas macht doch nur Arbeit zuzüglich Ärger im Bug-Tracker, wenn jemand eine andere Reihenfolge bekommt als erwartet.

                dedlfix.

                1. Hallo dedlfix,

                  Gibts das auch für den hier vorliegenden Fall mit application/x-www-form-urlencoded?

                  Sorry. Da hab ich mich mit den multipart/formdata verlaufen.

                  Aber vermutlich kennst Du die Antwort schon.

                  Sie ist Jein - es ist kein RFC, sondern Teil der HTML Spec. Die ist mir jetzt aber zu lang und zu rekursiv, um festzustellen ob sie was über doppelte Feldnamen sagt. In HTML 5.2, §4.10.21.4 steht jedenfalls nichts über den Umgang mit Duplicates.

                  Rolf

                  --
                  sumpsi - posui - clusi
                  1. Tach!

                    Für mich ist letztlich nicht entscheidend, ob das was durch eine RFC abgedeckt ist. Die gibt am Ende auch keine Garantie, ihr Inhalt auch in allen relevanten Clients umgesetzt ist.

                    Mir ist diese Lösung nur als erstes eingefallen, vermutlich wegen ihrer trickreichen Art, das Problem zu lösen. Ansonsten ist der Weg vom Entgegennehmen der Eingaben bis zur Stelle, an der die Geschäftslogik anfängt, Entscheidungen zu treffen, immer derselbe und eine Aufgabe für das verwendete Framework, inklusive einer ordentlichen Umsetzung in einen Boolean-Wert (im Fall der Checkboxen). Im Falle des OP ist die Prüfung auf Serverseite wohl die bessere Lösung, die auch in dem theoretischen Falle eines Problembrowsers zuverlässig arbeitet.

                    dedlfix.

                  2. hi,

                    Gibts das auch für den hier vorliegenden Fall mit application/x-www-form-urlencoded?

                    Sorry. Da hab ich mich mit den multipart/formdata verlaufen.

                    Dieser Enctype transportiert ein Array. Wobei die einzelnen Arrayelemente jeweils Schlüssel/Werte Paare sind. Das kann man kurz und knapp als [{},{}..] skizzieren.

                    Unabhängig davon dürfen in einem Array Elemente durchaus mehrfach vorkommen und auch deren Reihenfolge ist definiert.

                    Die Spezifikation für application/x-www-form-urlencoded hingegen sieht vor, daß mehrere Parameter mit demselben namen Ein Array bilden. Abstrakt transportiert dieser Enctype eine Struktur wie folgt:

                    # names=foo;names=bar;names=usw;number=123
                    
                    $stuct = {
                      names  => ['foo','bar','usw'],
                      number => 123
                    };
                    

                    Schon aufgrund unterschiedlicher Strukturen ergibt sich ein unterschiedlicher serverseitiger Umgang mit diesen Enctypes. Während multipart/form-data grundsätzlich ein Array transportiert, steckt in dem anderen Enctype ein Hash in dem die Werte ggf. Arrays sind.

                    PHP jedoch orientiert sich an einer bestimmten Schreibweise der Parameternamen

                    # addr[name]=Otto&addr[vname]=Hans&addr[plz]=99999&number[][][]=123&person=admin
                    
                    Array
                    (
                        [addr] => Array
                            (
                                [name] => Otto
                                [vname] => Hans
                                [plz] => 99999
                            )
                    
                        [number] => Array
                            (
                                [0] => Array
                                    (
                                        [0] => Array
                                            (
                                                [0] => 123
                                            )
                    
                                    )
                    
                            )
                    
                        [person] => admin
                    )
                    
                    

                    So liegen die Fakten. Man muss sich nur damit befassen dann versteht man das auch.

                    MfG

                    1. Hallo pl,

                      Die Spezifikation für application/x-www-form-urlencoded hingegen sieht vor, daß mehrere Parameter mit demselben namen Ein Array bilden.

                      Interessant. Hast Du dafür eine Quelle? rolfrost.de ist Sekundär- bis Tertiärliteratur und ohnehin Dein Produkt, damit also für Dich nicht als Beleg-Quelle gültig, sorry. Und wie sähe der Request-Body in diesem Fall spec-konform aus?

                      Wie gesagt - mit multipart/form-data bin ich 'reingefallen. Da wird jedes Feld als eigenes Part übertragen. Aber bei x-www-form-urlencoded war ich bisher der Meinung, dass die HTML-Definition keinerlei Semantik in den Namen oder Werten vorschreibt; das ist Sache der Application.

                      Rolf

                      --
                      sumpsi - posui - clusi
                      1. hi

                        Die Spezifikation für application/x-www-form-urlencoded hingegen sieht vor, daß mehrere Parameter mit demselben namen Ein Array bilden.

                        Interessant. Hast Du dafür eine reputable Quelle (rolfrost.de ist Sekundär- bis Tertiärliteratur und damit keine Quelle, sorry). Und wie sähe der Request-Body in diesem Fall spec-konform aus?

                        Genauso wie der QueryString.

                        Wie gesagt - mit multipart/form-data bin ich 'reingefallen. Da wird jedes Feld als eigenes Part übertragen. Aber bei x-www-form-urlencoded war ich bisher der Meinung, dass die HTML-Definition keinerlei Semantik in den Namen oder Werten vorschreibt; das ist Sache der Application.

                        Die RFC ist wie vom Erdboden verschluckt. Aber ich guck mal in CGI.pm vielleicht steht sie da noch drin, auch die Spec.

                        MfG

                        1. Hallo pl,

                          Genauso wie der QueryString.

                          In Query-Strings gibt's eine Definition für Array-Parameter?

                          Rolf

                          --
                          sumpsi - posui - clusi
                          1. hi

                            Genauso wie der QueryString.

                            In Query-Strings gibt's eine Definition für Array-Parameter?

                            Genauso wie der QueryString heißt:

                            bezogen auf den enctype="application/x-www-form-urlencoded"

                            daß der Content der bei GET als QueryString an den URL gehängt wird, bei einem POST im message Body liegt. D.h. er wird genauso geparst.

                            MfG

                            PS: PHP Parser nimmt bei gleichnamigen Parametern nur den Letzten. name=foo&name=bar also bar. Es sei denn die Namen genügen dem Syntax name[] oder name[key] oder name[][][][..] was eine proprietäre Festlegung seitens PHP ist.

                            Daß man mit einer bestimmten Name Konvention Daten strukturieren kann ist aber auch nichts Neues. Man könnte genausogut einen Punkt verwenden like addr.person.name und sieha da, davon lebt die ganze OOP Welt.

                            1. Hallo pl,

                              Rekursion -> siehe Rekursion...

                              Du hast gesagt, Array-Parameter im body eines POST-Requests werden genauso x-www-form-urlencoded aufgebaut wie im Query-String.

                              Bei Rückfrage "Wie sieht das genau aus?" verweist Du auf den Post-Body.

                              Äh??? Könntest Du ein Beispiel zeigen, wie man ein Array exakt und normgerecht urlencoden müsste? PHP-proprietäre Angaben mal beiseite, dass die nicht normgerecht sind hast Du ja schon vorher angemerkt.

                              Rolf

                              --
                              sumpsi - posui - clusi
                              1. Tach!

                                Äh??? Könntest Du ein Beispiel zeigen, wie man ein Array exakt und normgerecht urlencoden müsste? PHP-proprietäre Angaben mal beiseite, dass die nicht normgerecht sind hast Du ja schon vorher angemerkt.

                                Das war für mich nur eine Aussage. Der Nachweis in Form eines Verweises auf die Norm steht ja noch aus.

                                Ich vermute mal, dass Array oder irgendeine andere Form von Datentyp nicht weiter relevant sind für die Norm. Wenn ich etwas dazu erfinden müsste, würde ich mir zwar Gedanken über die Anforderungen machen, die die Systeme haben könnten, aber ansonsten eine agnostische Lösung suchen. Key-Value jeweils als Strings, ohne Einschränkungen bei den Keys, also auch Dopplungen zulassend, ist ein sehr einfaches Prinzip und trotzdem oder gerade deswegen sehr flexibel. Was die Systeme zum Weiterverarbeiten draus machen, ob sie Arrays bilden oder nicht, wäre mir sowas von egal. Das ist deren Problem, wie sie im Innern damit umgehen und was sie da für Möglichkeiten haben. Zeichenfolgen werden sie wohl alle verarbeiten können, ebenso das Konvertieren dieser in jede ihnen genehme Form. Wenn PHP aus foo[] ein Array macht ... soll es doch, wer hat denn dabei Nachteile? Aus Browsersicht sehe ich keinen prinzipiellen Unterschied zwischen

                                <input name="foo[]">...<input name="foo[]">

                                und

                                <input name="foo">...<input name="foo">

                                oder auch

                                <input name="无论​什么">...<input name="无论​什么">

                                Ein Name ist ein Name. In HTML4.01 ist das ein CDATA-Wert, der nur sehr wenige Einschränkungen im Bereich Steuerzeichen und Whitespace hat. Die HTML5-Spec ist mir zu mühsam, da kann es aber auch nicht schlechter geworden sein.

                                dedlfix.

                              2. hi

                                Rekursion -> siehe Rekursion...

                                Du hast gesagt, Array-Parameter im body eines POST-Requests werden genauso x-www-form-urlencoded aufgebaut wie im Query-String.

                                Bei Rückfrage "Wie sieht das genau aus?" verweist Du auf den Post-Body.

                                Äh??? Könntest Du ein Beispiel zeigen, wie man ein Array exakt und normgerecht urlencoden müsste?

                                ['A','B','C'] <=> name=A&name=B&name=C

                                Daß gleichnamige Felder ein Array bilden legt ja schon die HTML Spec. fest. Und wie sich diese im Content-Type: application/x-www-form-urlencoded wiederfinden siehe oben. Das machen alle Browser so weil sie diesen Enctype implementieren. Und das Encoding ist wieder eine andere Sache, dafür ist auch der Begriff Prozentkodierung geläufig. Die Prozentkodierung hat mit dem Array gar nichts zu tun, damit werden nur bestimmte Oktetten kodiert und natürlich die Trennzeichen wenn diese selbst in den values vorkommen.

                                Siehe auch: encodeURI und encodeURIComponent. Sowie decode~, URI::Escape usw. und das ist in RFC 3986 beschrieben.

                                MfG

                                1. Hallo pl,

                                  ach so hattest Du das gemeint. Da hatte ich Dich falsch verstanden, ich dachte, du hättest eine Notation speziell für Arrays gemeint. Ok. Mehrfache Namen. Hätte ich mir denken sollen, war ja eh Thema.

                                  Die RFC ist wie vom Erdboden verschluckt.

                                  D.h. die entsprechende Spec müssen wir jetzt noch wieder ausgraben, um zu wissen, dass die Interpretation dieser Notation als Array gesehen werden MUSS, und nicht wie vom PHP-Hund als "die letzte Duftmarke zählt".

                                  Aber letztlich - die Millionen PHP Fliegen sitzen nun schon auf dem 💩[]...

                                  Rolf

                                  --
                                  sumpsi - posui - clusi
                                  1. hi,

                                    D.h. die entsprechende Spec müssen wir jetzt noch wieder ausgraben, um zu wissen, dass die Interpretation dieser Notation als Array gesehen werden MUSS,

                                    Es geht ja gar nicht anders mit dem Enctype application/x-www-form-urlencoded.

                                    Es ist nur eine Frage, wie man das serverseitig handhabt. Nur, ich würde keine []~Klammern nehmen wie PHP das macht, sondern Punkte wie das in OOP allgemein geläufig ist.

                                    Und ob man aus gleichnamigen Feldern, die keiner speziellen Nomenklatur angehören auch ein Array bilden soll, würde ich IMMER mit JA beantworten und die Werte nicht einfach ignorieren sondern nutzen.

                                    Wobei es schon seit Jahren an der Zeit ist, über zweckmäßigere Enctypes nachzudenken. Schließlich gehts ja auch um eine saubere Trennung von action~Parameters und Nutzdaten.

                                    MfG

                  3. Tach!

                    Gibts das auch für den hier vorliegenden Fall mit application/x-www-form-urlencoded?

                    Sie ist Jein - es ist kein RFC, sondern Teil der HTML Spec. Die ist mir jetzt aber zu lang und zu rekursiv, um festzustellen ob sie was über doppelte Feldnamen sagt. In HTML 5.2, §4.10.21.4 steht jedenfalls nichts über den Umgang mit Duplicates.

                    Der relevante Satz in der HTML4.01-Spezifikation ist hingegen schön kurz. Dopplungen erwähnt er nicht, aber ich denke, die sind in der Formulierung inbegriffen:

                    2. The control names/values are listed in the order they appear in the document.

                    Also sehe ich das auch als abgesegnet an.

                    dedlfix.

              2. hmm

                Danke an PL für den Tipp mit den RFC.

                Es tut mir oft genug leid wenn ich sehe wie uralt diese RFCs sind. Außer application/x-www-form-urlencoded und multipart/form-data kennen Browser seither keine weiteren Enctypes, da haben definitiv einige Leute die Zeit verpennt!

                Immerhin hat man mit PHP erste Schritte dahingehend unternommen infolge einer bestimmten Nomenklatur hinsichtlich Parameternamen etwas mehr Struktur in die Parameterliste zu kriegen aber so wirklich durchgesetzt hat sich das auch nicht, geschweige denn daß ein RFC daraus geworden ist. An der Armseligkeit der verfügbaren legacy Enctypes hat das ja auch nichts geändert, ist also PHP intern irgndwo steckengeblieben (Knieschuss).

                Da lob ich mir schon meinen eigenen Parser der parst sogar JSON wenn der Request den header application/json setzt und zwar so daß ich nicht eine Zeile Code ändern muss wenn ich Clientseitig auf einen anderen Enctype umstelle.

                MfG

      3. Moin @Meowsalot,

        ich habe nochmals geschaut …

        und was sagt die Fehlerbehandlung von bind_param und execute?

        … und damit ist mir folgendes aufgefallen. Wenn alle Checkbox angeklickt sind, dann bekomme ich ein Insert. Es kann doch nicht sein, dass ich immer alle ausfüllen muss?

        Sind in deiner Tabelle alle Felder als NOT NULL ohne DEFAULT deklariert?

        Viele Grüße
        Robert

  2. könnt ihr mir sagen wo hier der Fehler liegt? Das Script macht kein Insert, bringt aber auch keine Fehlermeldung

     if($stmt = $mysqli->prepare("INSERT INTO user_anwesenheit_tage (uat_userid, uat_mo, uat_di, uat_mi, uat_do, uat_fr, uat_sa, uat_so)  
                                        VALUES (?, ?, ?, ?, ?, ?, ?, ?)"))
            {
                $stmt->bind_param("ssssssss", $user, $_POST["uat_mo"], $_POST["uat_di"], $_POST["uat_mi"], $_POST["uat_do"], $_POST["uat_fr"], $_POST["uat_sa"], $_POST["uat_so"]);          
                $stmt->execute();
                }
                else {
                    echo $mysqli -> error;
                }
    

    Das Script prüft nur ob prepare und nicht bind_param oder execute einen Fehler melden.