MySQL findet keine Datensätze, wenn id in Anführungszeichen steht

Einklappen
X
 
  • Filter
  • Zeit
  • Anzeigen
Alles löschen
neue Beiträge

  • MySQL findet keine Datensätze, wenn id in Anführungszeichen steht

    Hallo ihr,

    ich habe ein seltsames Problem: MySQL (Version 5.5.9) findet Datensätze nicht, wenn deren id in einfachen Anführungszeichen geschrieben ist.

    Das heißt, mit folgendem Setup

    Code:
    CREATE TABLE `Play` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `user_id` int(11) DEFAULT NULL,
      `room_id` int(11) DEFAULT NULL,
      PRIMARY KEY (`id`),
      KEY `IDX_FEBB7184A76ED395` (`user_id`),
      KEY `IDX_FEBB718454177093` (`room_id`)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
    
    CREATE TABLE `User` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      `username` varchar(255) NOT NULL,
      `nickname` varchar(255) NOT NULL,
      `email` varchar(255) NOT NULL,
      PRIMARY KEY (`id`),
      UNIQUE KEY `UNIQ_2DA17977F85E0677` (`username`),
      UNIQUE KEY `UNIQ_2DA17977A188FE64` (`nickname`),
      UNIQUE KEY `UNIQ_2DA17977E7927C74` (`email`)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=1 ;
    
    INSERT INTO `User` VALUES(1, 'user', 'nickname', 'user@user.de');
    
    CREATE TABLE `Room` (
      `id` int(11) NOT NULL AUTO_INCREMENT,
      PRIMARY KEY (`id`)
    ) ENGINE=InnoDB  DEFAULT CHARSET=utf8 AUTO_INCREMENT=32 ;
    
    INSERT INTO `Room` VALUES(32);
    
    ALTER TABLE `Play`
      ADD CONSTRAINT `play_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `User` (`id`),
      ADD CONSTRAINT `play_ibfk_2` FOREIGN KEY (`room_id`) REFERENCES `Room` (`id`);
    Und dem folgenden Statement
    Code:
    INSERT INTO  `woe`.`Play` (`id` ,`user_id` ,`room_id`)
    VALUES (NULL ,  '1',  '32')
    erhalte ich den Fehler.
    #1452 - Cannot add or update a child row: a foreign key constraint fails (`woe`.`play`, CONSTRAINT `play_ibfk_1` FOREIGN KEY (`user_id`) REFERENCES `User` (`id`))
    Da ich das Statement nicht manuell ändern kann, da es automatisch von einer Bibliothek erzeugt wird (Doctrine), kann der Fehler nur im MySQL liegen. Nach meinem Wissensstand, sind DBS in der Lage, zu casten. D.h. es sollte keinerlei Unterschied machen, ob ich das obige Statement oder

    Code:
    INSERT INTO  `woe`.`Play` (`id` ,`user_id` ,`room_id` ,)
    VALUES (NULL ,  1,  32)
    auf die Datenbank absetze. Es sollte in beiden Fällen funktionieren. Tut es aber nur in Zweiterem. Beide Felder in den anderen Tabellen existieren offensichtlich, mit den korrekten IDs.

    Was läuft da schief?

    PS: Das erste Statement wurde sogar durch PMA (Version 3.3.9.2) automatisch erzeugt, wenn ich auf der Oberfläche einen neuen Datensatz in `Play` einfügen will.
    Zuletzt geändert von ApoY2k; 07.08.2011, 13:00.
    This is what happens when an unstoppable force meets an immovable object.

  • #2
    Geht bei mir problemlos.

    Welche Version hat der MySQL-Server?

    Kommentar


    • #3
      MySQL 5.5.9 und PHPMyAdmin 3.3.9.2
      This is what happens when an unstoppable force meets an immovable object.

      Kommentar


      • #4
        Vorbildliche Problembeschreibung - gleich per Copy&Paste testbarer Code, so wünscht man sich das

        Problem aber nicht nachvollziehbar (MySQL Server Version 5.5.11), zumindest wenn ich das INSERT-Statement über pma ausführe. Hast du das Problem auch, wenn du das von dort aus versuchst, oder nur aus deiner Applikation heraus?
        I don't believe in rebirth. Actually, I never did in my whole lives.

        Kommentar


        • #5
          Zuerst kam er eben nur in der Applikation. Dann hab ich solange debuggt, bis ich heraus fand, was für ein Statement er absetzt. Dieses habe ich dann in PMA getestet, und der Fehler erschien.

          Falls es wichtig ist: Das ganze läuft auf OS X 10.6.8

          PS: Gern geschehen
          This is what happens when an unstoppable force meets an immovable object.

          Kommentar


          • #6
            Zitat von ApoY2k Beitrag anzeigen
            Falls es wichtig ist: Das ganze läuft auf OS X 10.6.8
            Ich denke, damit wird es weniger zu tun haben - eher mit der Server-Konfiguration.

            Es könnte an sowas wie dem STRICT MODE liegen,
            MySQL :: MySQL 5.5 Reference Manual :: 5.1.6 Server SQL Modes :
            Strict mode controls how MySQL handles input values that are invalid or missing. A value can be invalid for several reasons. For example, it might have the wrong data type for the column, or it might be out of range.
            Schau mal, ob der aktiviert ist, und wenn ja, ob sich am Verhalten was ändert, wenn du den deaktivierst.
            I don't believe in rebirth. Actually, I never did in my whole lives.

            Kommentar


            • #7
              Ne daran lags auch nicht, hatte ich schon geprüft.

              Ich habe noch weiter recherchiert und dann kam folgendes raus:

              MySQL Bugs: #60309: MySQL 5.5.9 for Mac OSX has bug with foreign key constraints

              Das passiert tatsächlich nur auf OS X 10.6 und mit MySQL 5.5.9 - Die Lösung ist, in die my.conf folgende Zeilen einzufügen

              Code:
              [mysqld]
              lower_case_table_names=1
              Ist mit neueren Versionen auf OS X wieder gefixt. Ich danke euch dennoch für euer Engagement! Auf sowas muss man auch erstmal kommen...
              This is what happens when an unstoppable force meets an immovable object.

              Kommentar


              • #8
                Kleiner Tipp für die Zukunft: Schreib Tabellen- und Spaltennamen immer klein.

                Kommentar


                • #9
                  Tue ich normalerweise - Das Datenbankschema wurde wie schon erwähnt von einer ORM-Bibliothek erzeugt (Doctrine - PHP Object Persistence Libraries and More) - Und diese hat einfach die Klassennamen als Tabellennamen übernommen... Das war das Problem

                  Wenn ich das Schema selbst erstelle schreibe ich sowieso alles klein...
                  This is what happens when an unstoppable force meets an immovable object.

                  Kommentar


                  • #10
                    OK, alles klar. Man kann Doctrine die Tabellen- und Spaltennamen selber vorgeben.

                    Kommentar


                    • #11
                      Jo das hab ich zur Sicherheit jetzt auch mal gemacht.

                      Ist aber echt seltsam, dass großgeschriebene Tabellennamen so einen Fehler verursachen können.

                      Und noch seltsamer finde ich, dass es ohne Anführungszeichen funktioniert hat. Man lernt eben nie aus.
                      This is what happens when an unstoppable force meets an immovable object.

                      Kommentar

                      Lädt...
                      X