Schieterle: MySQL 5.0.18 und Datumswerte

Hallöchen zusammen,

ich habe da ein Problem mit der MySQL Version 5.0.18..

Es geht darum, dass ich eine Tabelle mit ca 5.000 Datensätzen habe (in MySQL Version 4.0.*). Einem Grossteil dieser Datensätze wurde ein Datum zugewiesen, anderen nicht.. Die Datensätze ohne Datum haben einen Defaultwert von "0000-00-00"..

Ich habe mir jetzt die Datensätze anzeigen lassen, die als Datumswert "0000-00-00" haben. Es waren 718 Datensätze betroffen..
Dann habe ich die Tabelle exportiert und in die MySQL Version 5.0.18 importiert..
In der MySQL Version 5.0.18 habe ich jetzt komischerweise 720 Datensätze mit dem Datumswert "0000-00-00" also 2 mehr als bei der älteren Version..

Das würde bedeuten, dass beim Import irgendwas schiefgelaufen ist (Fehler beim Export kann ich ausschliessen, da ich es mit anderen Versionen getestet habe)..
Irgendwelche Datumswerte scheint MySQL 5.0.18 falsch zu interpretieren und macht deswegen "0000-00-00" aus ihnen.

Hat jemand schonmal so einen Fehler gehabt, bzw. eine Idee, wie ich am besten bei der Suche nach den falschen Datumswerten vorgehen kann? Ich möchte ungern alle Werte per Hand kontrollieren.

Gruss
Schieterle

  1. Moin!

    Ich habe mir jetzt die Datensätze anzeigen lassen, die als Datumswert "0000-00-00" haben. Es waren 718 Datensätze betroffen..
    Dann habe ich die Tabelle exportiert und in die MySQL Version 5.0.18 importiert..
    In der MySQL Version 5.0.18 habe ich jetzt komischerweise 720 Datensätze mit dem Datumswert "0000-00-00" also 2 mehr als bei der älteren Version..

    Wenn du feststellen könntest, welche zwei Datensätze das sind, könnte man deren Datumswert in der alten DB ermitteln, oder gar deren erzeugendes SQL-Statement in der Exportdatei.

    Hat jemand schonmal so einen Fehler gehabt, bzw. eine Idee, wie ich am besten bei der Suche nach den falschen Datumswerten vorgehen kann? Ich möchte ungern alle Werte per Hand kontrollieren.

    Wenn du dir einen String mit allen 718 IDs aus der alten Datenbank zusammenbastelst, und diesen dann in "WHERE Datum = "0000-00-00" and ID not in (IDSTRING)" einbaust, kriegst du sehr wahrscheinlich genau die zwei Datensätze, die zusätzlich das falsche Datum haben.

    - Sven Rautenberg

    --
    My sssignature, my preciousssss!
    1. Hi,

      [...] Statt den ID-String von Hand zu basteln könnte man auch nochmal einen weiteren Export aus der 4er ziehen, diesmal nur mit den Sätzen die das "0000-00-00"-Datum haben. Das importiert man in der 5er in eine weitere Tabelle und lässt dann ein
      SELECT FROM allesätze WHERE id NOT IN (SELECT FROM 0-sätze)
      laufen.

      MfG
      Rouven

      --
      -------------------
      ie:| fl:| br:> va:| ls:& fo:) rl:( n4:{ ss:) de:] js:| ch:? mo:} zu:|
      1. Hi,

        [...] Statt den ID-String von Hand zu basteln könnte man auch nochmal einen weiteren Export aus der 4er ziehen, diesmal nur mit den Sätzen die das "0000-00-00"-Datum haben. Das importiert man in der 5er in eine weitere Tabelle und lässt dann ein
        SELECT FROM allesätze WHERE id NOT IN (SELECT FROM 0-sätze)
        laufen.

        MfG
        Rouven

        Hört sich nach einer guten Idee an.. Ich werde mir gleich mal was zusammenbasteln um die beiden Werte zu ermitteln.. Bin mal gespannt darauf, wie die Datumswerte aussehen, die scheinbar zum Fehler führten..

        1. Fehler gefunden. Die zwei fehlerhaften Datumswerte sahen folgendermaßen aus:

          0167-02-29

          Nicht nur, dass das Jahr falsch eingegeben wurde (was aber wenigstens keinen Fehler verursacht hat), es wurde darüber hinaus der 29. Februar angegeben. Und im Jahre 167 hatte der Februar scheinbar nur 28 Tage :D..

          Also, es lag tatsächlich am Tag des eingegebenen Datums.
          Etwas schade, dass der Wert dann einfach auf 0 gesetzt wird, statt vielleicht eine Meldung auszugeben. Denn schliesslich ist es ja ein offentsichtlicher Fehler.

          Vielen Dank für eure Hilfe!

          1. Moin!

            Also, es lag tatsächlich am Tag des eingegebenen Datums.
            Etwas schade, dass der Wert dann einfach auf 0 gesetzt wird, statt vielleicht eine Meldung auszugeben. Denn schliesslich ist es ja ein offentsichtlicher Fehler.

            Auf der von Vinzenz verlinkten Seite ist nachzulesen, dass es eine Option gibt, die MySQL zum Meckern über ungültige Daten veranlassen kann.

            Wenn du die nicht nutzt - dein Problem. ;) (Ja klar, erstmal wissen, dass die Daten unerwartet falsch sind, und dann wissen, dass es da so eine Option gibt, die eventuell meckert, und die dann noch richtig konfigurieren ... klingt unrealistisch, aber dafür gibts eben das Forum.)

            - Sven Rautenberg

            --
            My sssignature, my preciousssss!
            1. »»(Ja klar, erstmal wissen, dass die Daten unerwartet falsch sind, und dann wissen, dass es da so eine Option gibt, die eventuell meckert, und die dann noch richtig konfigurieren ... klingt unrealistisch, aber dafür gibts eben das Forum.)

              • Sven Rautenberg

              Naja, wenigstens kenne ich jetzt den Fehler und weiss, dass MySQL 5 sich da doch ziemlich anders verhält als seine Vorgänger. Darauf kann man ja aufbauen. Als erstes kommt jetzt eine vernünftige Validierung bei der Eingabe der Daten.

  2. Hallo

    ich habe da ein Problem mit der MySQL Version 5.0.18..

    oder in Deinen Ausgangsdaten in der älteren Version ;-)

    Ich habe mir jetzt die Datensätze anzeigen lassen, die als Datumswert "0000-00-00" haben. Es waren 718 Datensätze betroffen..
    Dann habe ich die Tabelle exportiert und in die MySQL Version 5.0.18 importiert..
    In der MySQL Version 5.0.18 habe ich jetzt komischerweise 720 Datensätze mit dem Datumswert "0000-00-00" also 2 mehr als bei der älteren Version..

    Das würde bedeuten, dass beim Import irgendwas schiefgelaufen ist (Fehler beim Export kann ich ausschliessen, da ich es mit anderen Versionen getestet habe)..

    Neben dem, was Sven bereits erwähnt hat, möchte ich http://dev.mysql.com/doc/refman/5.0/en/datetime.html#id2955865 als möglichen Grund für die zwei zusätzlichen "0000-00-00"-Werte ins Spiel bringen.

    Irgendwelche Datumswerte scheint MySQL 5.0.18 falsch zu interpretieren und macht deswegen "0000-00-00" aus ihnen.

    Seit MySQL 5.0.2 (s.o.) geht MySQL restriktiver mit ungültigen Datumswerten um. Ich finde das richtig. Wäre dies der Grund für die zwei zusätzlichen Werte, so gib' nicht MySQL 5.0.18 die Schuld, sondern der alten Version.

    Freundliche Grüße

    Vinzenz