Neuigkeiten
  • Die modified eCommerce Shopsoftware ist kostenlos, aber nicht umsonst.
    Spenden
  • Damit wir die modified eCommerce Shopsoftware auch zukünftig kostenlos anbieten können:
    Spenden
  • Thema: MySQL8 - #1067 - Fehlerhafter Vorgabewert (DEFAULT) für 'address_date_added'

    KJoe

    • Fördermitglied
    • Beiträge: 66
    Nabend mal. ich glaube, irgendjemand arbeitet bei unserem Provider, der uns absolut nicht leiden kann.

    Seit Umstellung auf MySQL8 erzeugt phpMyAdmin den Fehler  #1067 - Fehlerhafter Vorgabewert (DEFAULT) für 'address_date_added' bei diversen Datenbankoperationen.

    Es ist jedoch nicht möglich, einen Alter oder Modify Befehl für die Spalte laufen zu lassen.  Denn dieser bringt genau den selben Fehler wieder...
    Lapidare Antwort vom Support:  Nullen sind beim Datum in MySQL8 nicht mehr erlaubt. Beheben Sie den Fehler und versuchen Sie es erneut.

    Hat jemand dafür eine Idee? Oder muss ich jetzt wirklich lokal einen eigenen älteren SQL Server aufsetzen, um alle 0en per Alter/Modify in ein leeres Feld zu ersetzen?

    Ich brauche bitte einen Gedankenstoß.
    Wenn plötzlich nichts mehr geht, fasst man leider keine klaren Gedanken mehr.  :-x
    Thx, Joe

    Linkback: https://www.modified-shop.org/forum/index.php?topic=43360.0

    Q

    • Fördermitglied
    • Beiträge: 1.536
    Teste mal
    Code: SQL  [Auswählen]
    ....DEFAULT CURRENT_TIMESTAMP
    ON UPDATE CURRENT_TIMESTAMP  
    ggf erstmal ohne ON UPDATE ... testen

    GTB

    • modified Team
    • Gravatar
    • Beiträge: 6.306
    • Geschlecht:
    Code: SQL  [Auswählen]
     SET SESSION sql_mode=''

    Damit sollte das Problem behoben sein. Schau mal ob du das in PMS dauerhaft setzen kannst.

    Ansonsten selber eine Version hochladen und in den Einstellungen hinterlegen.

    Gruß Gerhard

    KJoe

    • Fördermitglied
    • Beiträge: 66
    Hallo Gerhard,

    beim Provider ist vermutlich hinterlegt - sql_mode=NO_ZERO_IN_DATE, NO_ZERO_DATE, NO_ENGINE_SUBSTITUTION
    Eine Änderung zur Korrektur der Datensätze in sql_mode=NO_ENGINE_SUBSTITUTION sei nicht möglich...

    Die Datenbank (es ist übrigens HostEurope) ist dort seit 2010 groß geworden und mitgewachsen. Die Möglichkeiten der Bearbeitung und Korrekturen hat jedoch immer weiter abgenommen und der Support.

    Kannst du das bitte mal ausschreiben?  ;-) " ... du das in PMS dauerhaft setzen kannst."

    Danke, Joe

    PS: Ich werde mal wieder versuchen, eine eigene neuere PhpMyAdminVersion zu installieren, um an die ini Datei ranzukommen...

    Q

    • Fördermitglied
    • Beiträge: 1.536
    @Gerhard: Ich vermute, dass wird jetzt öfter jemand auf die Füße fallen.

    Zitat
    Note
    The following examples use DEFAULT 0, a default that can produce warnings or errors depending on whether strict SQL mode or the NO_ZERO_DATE SQL mode is enabled. Be aware that the TRADITIONAL SQL mode includes strict mode and NO_ZERO_DATE. See Section 7.1.11, “Server SQL Modes”.

    MySQL 8.0 Reference Manual  /  ...  /  Automatic Initialization and Updating for TIMESTAMP and DATETIME

    Vielleicht sollte das grundsätzlich betrachtet und Zeit-/Datumfelder mit DEFAULT Werten belegt werden. Inwieweit NULL hier auch eine Option ist, müsste man mit den Serversettings mal testen.

    @KJoe: Just nice to know. NULL ist nicht gleich 0 (zero)

    KJoe

    • Fördermitglied
    • Beiträge: 66
    Kurzer Hinweis zu diesem Problem - ich weiß nicht, ob unser Provider was "gebogen" hat.
    Jedoch Lassen sich die Standardwerte tatsächlich mit CURRENT_TIMESTAMP ersetzen, wenn man beides in einem Rutsch erledigt.
    Also beide Spalten markieren, > Edititieren > abspeichern fertig. 
    Dann bleiben nur noch die bis dato eingetragenen Standardwerte '0000-00-00 00:00:00' drüber.
    Aber dazu habe ich ein neues Thema angefangen. Ich möchte nicht unbedingt die Fehlermeldung mit einer möglichen Änderung in der db vermengen.
    Damit können Suchende später wenig anfangen.

    Zu den möglichen Auswirkungen von Abänderungen, bitte hier weiter schreiben >>
    https://www.modified-shop.org/forum/index.php?topic=43363.0

    Thx, Joe

    klabund

    • Neu im Forum
    • Beiträge: 11
    Dazu fällt mir ein, dass es einen Datumstyp gab (oder immer  noch gibt), der nicht im Jahr Null begann, sondern - man glaubt's ja nicht - am 1. Januar 1000. Dieser Datumstyp war auch in früheren Modified-Versionen vorhanden. Im Allgemeinen gab es keine Probleme, irgendwie hat MySql das toleriert (?), aber manchmal eben doch nicht. Dann wurde nichts eingefügt plus Absturz. Ich meine, das wurde in neueren Versionen beseitigt. Lösung war eine Änderung des Datumstyps. Kann aber wegen Auslandsaufenthalt gerade  nicht in meiner alten MySql-Referenz nachsehen, was das war.

    Q

    • Fördermitglied
    • Beiträge: 1.536
    Ich hätte auf TIMESTAMP (Unixtime) getippt. Beginnt am 01.01.1970
    2 Antworten
    2416 Aufrufe
    07. April 2011, 19:37:26 von Alexis
    5 Antworten
    2600 Aufrufe
    28. Januar 2015, 18:58:40 von WeXsler
    5 Antworten
    4351 Aufrufe
    18. August 2011, 23:16:10 von franky_n