błąd mysql 1364 Pole nie ma wartości domyślnych

113

Mój stół wygląda

create table try ( name varchar(8), CREATED_BY varchar(40) not null);

a następnie mam wyzwalacz do automatycznego wypełniania pola CREATED_BY

create trigger autoPopulateAtInsert BEFORE INSERT on try for each row set new.CREATED_BY=user();

Kiedy robię wkładkę za pomocą

insert into try (name) values ('abc');

wpis jest wykonany w tabeli, ale nadal otrzymuję komunikat o błędzie

Field 'CREATED_BY' doesn't have a default value Error no 1364

Czy istnieje sposób na wyeliminowanie tego błędu bez dopuszczania wartości zerowej pola ORAZ bez usuwania wyzwalacza? W przeciwnym razie moja hibernacja zobaczy te wyjątki (mimo że wstawki zostały wykonane), a następnie aplikacja ulegnie awarii.

kk1957
źródło

Odpowiedzi:

28

Ustaw wartość domyślną Created_By(np.: Pusty VARCHAR), a wyzwalacz i tak zaktualizuje tę wartość.

create table try ( 
     name varchar(8), 
     CREATED_BY varchar(40) DEFAULT '' not null
);
KinSlayerUY
źródło
Jak ustawić wartość domyślną w programie Java?
Nagarajan Shanmuganathan
1
potrzebujesz domyślnej wartości w definicji tabeli (create table try (name varchar (8), CREATED_BY varchar (40) DEFAULT '' not null))
KinSlayerUY
Nie rozwiązuje to problemu głównego. Zobacz znacznie bardziej obszerną odpowiedź Phyxx poniżej.
csvan
3
Odpowiedź @csvan Phyxx nie odnosi się również do głównej przyczyny, ponieważ główną przyczyną był błąd w MySQL, który został naprawiony w wersji 5.7.1 - zobacz odpowiedź B98: stackoverflow.com/a/29854279/5389997 Usunięcie trybu strict_trans_table sql sprawia, że ​​MySQL jest bardziej podatne na błędy jakości danych, więc usunięcie ich nie jest dobrą radą.
Shadow
205

Jest to spowodowane STRICT_TRANS_TABLEStrybem SQL zdefiniowanym w

% PROGRAMDATA% \ MySQL \ MySQL Server 5.6 \ my.ini

plik. Usunięcie tego ustawienia i ponowne uruchomienie MySQL powinno rozwiązać problem.

Zobacz https://www.farbeyondcode.com/Solution-for-MariaDB-Field--xxx--doesn-t-have-a-default-value-5-2720.html

Jeśli edycja tego pliku nie rozwiąże problemu, zobacz http://dev.mysql.com/doc/refman/5.6/en/option-files.html, aby poznać inne możliwe lokalizacje plików konfiguracyjnych.

Phyxx
źródło
5
Możesz uruchomić zapytanie SQL w swoim narzędziu do zarządzania bazą danych, takim jak phpMyAdmin: -- verified that the mode was previously set select @@GLOBAL.sql_mode; -- UPDATE MODE SET @@global.sql_mode= 'YOUR_VALUE';
anasanjaria,
5
ale może chcesz STRICT_TRANS_TABLES?
Andrew,
w moim przypadku pole jest typu DATETIME z domyślną wartością NULL i nadal widzę ten sam błąd, mam dwa schematy w tej samej bazie danych. jeden do stagingu, drugi do produkcji, z taką samą strukturą stołu. Działa w jednym schemacie, ale nie działa w innym z dokładnie taką samą strukturą tabeli w obu. Jestem zdumiony .. Nie jestem pewien, czy jest to problem z STRICT_TRANS_TABLES
dresh
1
Usunąłem STRICT_TRANS_TABLES z /etc/my.cnf - w linii zaczynającej się od sql_mode - i ponownie uruchomiłem usługę mysql i problem zniknął.
Mike Volmar
92

Otwórz phpmyadmin, przejdź do zakładki „Więcej” i wybierz podmenu „Zmienne”. Przewiń w dół, aby znaleźć tryb sql. Edytuj tryb sql i usuń „STRICT_TRANS_TABLES” Zapisz go.

Nilesh Dhangare
źródło
22
To pytanie dotyczy MySQL i nie wspomina o phpmyadmin. Proszę, nie zakładaj, że wszyscy mają taki bieg.
Chris,
2
@ jackadams49 Ta zmiana nie obowiązuje. Czy możesz mi doradzić, co zrobiłeś, aby ta zmiana przetrwała ponowne uruchomienie systemu?
LD James,
8
@ jackadams49, aby pozostać, sudo nano /etc/mysql/my.cnfdodaj [mysqld] sql_mode = "ONLY_FULL_GROUP_BY,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION", zapisz i wyjdź, a następnie uruchom ponownie mysql sudo service mysql restart
maan81
1
Aby dodać, musiałem zmienić wartości sql_modena null, czyli sql_mode = ""dla innych podobnych błędów.
maan81
Niedawno zaktualizowaliśmy MySQL do wersji 5.7. Mieliśmy zbyt wiele problemów. To zadziałało dla mnie. Uratowałem mój dzień.
Uczeń
38

W phpmyadmin wykonaj następujące czynności:

select @@GLOBAL.sql_mode

W moim przypadku otrzymuję:

ONLY_FULL_GROUP_BY, STRICT_TRANS_TABLES ,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION

Skopiuj ten wynik i usuń STRICT_TRANS_TABLES. Następnie wykonaj następujące czynności:

set GLOBAL sql_mode='ONLY_FULL_GROUP_BY,NO_ZERO_IN_DATE,NO_ZERO_DATE,ERROR_FOR_DIVISION_BY_ZERO,NO_AUTO_CREATE_USER,NO_ENGINE_SUBSTITUTION'
Kamil
źródło
ya, ale w tym celu musisz zalogować się do phpmyadmin za pomocą konta root :) super konto
user889030
1
po spędzeniu czterech godzin to rozwiązanie działało u mnie w Ubuntu 16.04. Świetny !
Waleed Ahmed
3
w ogóle nie potrzebujesz phpmyadmin, użyj tych poleceń w mysqlwierszu poleceń.
gustyaquino
4
spowoduje to zresetowanie do wartości domyślnych po ponownym uruchomieniu mysql / server / pc. Trzeba edycji /etc/mysql/mysql.conf.d/mysqld.cnf i po [mysqld] dodaj wiersz: sql_mode = 'ONLY_FULL_GROUP_BY, NO_ZERO_IN_DATE, NO_ZERO_DATE, ERROR_FOR_DIVISION_BY_ZERO, NO_AUTO_CREATE_USER, NO_ENGINE_UBSTITUTION'
waza123
rozwiązanie autorstwa @ waza123, to działa dla mnie po aktualizacji do mysql 5.7.20. dzięki
fredy kardian
28

Kiedy miałem ten sam problem z mysql5.6.20 zainstalowanym z Homebrew, rozwiązałem go, przechodząc do my.cnf

nano /usr/local/Cellar/mysql/5.6.20_1/my.cnf

Znajdź linię, która wygląda tak:

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

Skomentuj powyżej linii i zrestartuj serwer mysql

mysql.server restart

Błąd zniknął!

Kingsley Ijomah
źródło
15

Uruchom konsolę mysql:

mysql -u your_username -p

wybierz bazę danych:

USE your_database;

i uruchom (także z konsoli mysql):

SET GLOBAL sql_mode='';

Spowoduje to wyłączenie trybu ścisłego, a mysql nie będzie już narzekać.

Dla jasności: definicja bazy danych mówi, że „to pole musi mieć zdefiniowaną wartość domyślną”, a wykonując kroki z góry, mówisz do MySql „neah, po prostu je zignoruj”. Więc jeśli chcesz tylko szybko naprawić lokalnie, to rozwiązanie jest w porządku. Ale generalnie powinieneś zbadać definicję swojej bazy danych i sprawdzić, czy pole naprawdę wymaga wartości domyślnej, a jeśli tak, ustaw ją. A jeśli wartość domyślna nie jest potrzebna, to wymaganie powinno zostać usunięte, aby uzyskać czysty stan.

MilanG
źródło
Tak, nie dodawaj wartości domyślnych, po prostu usuń reguły, świetne rozwiązanie (sugerowane sarkazm) nigdy nie rób tego świetnego złego przykładu. To jednak rozwiązuje problem
zardilior
1
Tak, zgadzam się z tobą. Ale czasami masz projekt innych osób, który działa dobrze, np. Na produkcji (gdzie nie jest ustawiony tryb ścisły) i chcesz po prostu dodać jakąś małą funkcję lub poprawkę błędu, działającą lokalnie. Nie chcesz walczyć ze smokami, tylko po to, żeby ta rzecz zadziałała. :)
MilanG,
na ten scenariusz zgadzam się
zardilior
@zardilior o co chodzi? wartość domyślna jest wybierana na podstawie typu kolumny, jeśli reguła zostanie usunięta. Nie widzę w tym nic złego: / ta reguła jest dość surowa bez powodu.
Reloecc
1
Wcale nie jest surowe, po prostu zmusza cię do zadeklarowania wartości domyślnej lub podania wartości, również tryb ścisły działa na znacznie więcej rzeczy niż tylko to, więc wyłączenie go, zamiast zadeklarować deault na kolumnie lub przekazać wartość, jest naprawdę straszne mor ein prod.
Wyłączasz
13

Jak powiedzieli inni, jest to spowodowane STRICT_TRANS_TABLEStrybem SQL.

Aby sprawdzić, czy STRICT_TRANS_TABLEStryb jest włączony:

SHOW VARIABLES LIKE 'sql_mode';

Aby wyłączyć tryb ścisły:

SET GLOBAL sql_mode='';
Damjan Pavlica
źródło
Ręcznie usunięto „STRICT_TRANS_TABLES” ze zmiennych> sql_mode do testowania i zadziałało!
Prem popatia
1
Uratowałeś mi dzień.
pępowina
U mnie po uruchomieniu drugiego polecenia i sprawdzeniu sql_mode (1. polecenie) nic nie robi. Nawet po ponownym uruchomieniu usługi mysql. Debian 9
trainoasis
12

Przed każdą czynnością wstawiania dodałem poniższy wiersz i rozwiązałem problem,

SET SQL_MODE = '';

Nie jestem pewien, czy to najlepsze rozwiązanie,

SET SQL_MODE = ''; INSERT INTO  `mytable` (  `field1` ,  `field2`) VALUES ('value1',  'value2');
Vinith
źródło
1
Nie trzeba tego robić przed każdą akcją wstawiania, wystarczy zrobić to raz na początku skryptu, zaraz po połączeniu się z bazą danych, a każde zapytanie insertowe będzie działać bez błędu „Pole nie ma wartości domyślnej”.
José Carlos PHP
To rozwiązanie jest dobre, ponieważ nie musisz zmieniać tabel (może być wiele pól do zmiany).
José Carlos PHP
11

Jego praca i przetestowana kopia do pliku konfiguracyjnego: /etc/mysql/my.cnf LUB /bin/mysql/my.ini

[mysqld]
port = 3306
sql-mode=""

następnie uruchom ponownie MySQL

Devraj Gupta
źródło
9

Zmodyfikuj zapytanie i dodaj „IGNORUJ” jako:

INSERT IGNORE INTO  `mytable` (  `field1` ,  `field2`) VALUES ('value1',  'value2');
Rohit Dhiman
źródło
to zadziałało dla mnie - mój skrypt PHP przerywał działanie, ale z IGNORE, po prostu reklamuje nowy wiersz! Teraz, jak "bezpieczne" jest posiadanie IGNORE zakodowanej na stałe w zapytaniu PHP-MYSQL? Używam tego do automatycznego dodawania wierszy dla nowego „dnia”, w którym wcześniej go nie było
Levchik,
@Levchik Kiedy używasz IGNORE, zamiast błędu MySQL wyświetla ostrzeżenie, gdy wystąpi błąd i spróbuje jakoś wykonać instrukcję: mysqltutorial.org/mysql-insert-ignore
Stefan
6

Użytkownicy Windows WampServer :

WAMP> MySQL> my.ini

wyszukaj plik sql-mode=""

Odkomentuj to.

Andrzej
źródło
2
W mojej wersji musiałem zmienić: sql-mode="STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER"sql-mode="STRICT_ALL_TABLES,ERROR_FOR_DIVISION_BY_ZERO,NO_ZERO_DATE,NO_ZERO_IN_DATE,NO_AUTO_CREATE_USER"na sql-mode="". Odkomentowanie sql-mode=""spowodowało błąd.
Julian,
5

Wydaje się, że jest to spowodowane długotrwałym (od 2004) błędem (# 6295) w MySQL , zatytułowanym

Wyzwalacze nie są przetwarzane dla kolumn NOT NULL .

Zostało to rzekomo naprawione w wersji 5.7.1 MySQL (Changelog, ostatni wpis) w 2013 roku, sprawiając, że MySQL zachowuje się „zgodnie ze standardem SQL” (ibid).

B98
źródło
Zaktualizowałem z 5.6 do 5.7.11 i problem został dla mnie naprawiony (a usunięcie STRICT_TRANS_TABLES nie działało dla mnie), więc głosuję za tym i odrzucam pozostałe odpowiedzi
knocte
5
@knocte Nie każdy może zaktualizować MySQL w swoim systemie, więc nie warto głosować na to.
JulienD
Jedyna odpowiedź, która naprawdę mi pomaga. Usunięcie NOT NULLograniczenia lub dodanie wartości domyślnej do kolumny rozwiązało problem. Wyzwalacz działa zgodnie z oczekiwaniami.
Ruslan Stelmachenko
3

W systemie Windows Server edytuj plik my.ini (na przykład program files \ mysql \ mysql server nn \ my.ini)

Nie chciałbym po prostu ustawić sql-mode = "", raczej sugeruję usunięcie STRICT_TRANS_TABLES z linii, pozostawienie wszystkiego tak, jak było, a następnie ponowne uruchomienie MySQL z narzędzia usług. Dodaj komentarz dla przyszłych programistów, kim jesteś i co zrobiłeś.

Bill Degnan
źródło
Ta odpowiedź mówi to samo. stackoverflow.com/a/52004654/10431118
karma4917
Ogólnie mówiąc tak, ale chodzi mi o to, że mówię konkretnie, aby nie wymazywać wszystkich wartości trybu sql, ale raczej usunąć tylko STRICT_TRANS_TABLES, ponieważ to wszystko, czego potrzebujesz. W przeciwnym razie możesz mieć wpływ na inne usługi.
Bill Degnan,
1

ustawiłem pola na niezerowe i problem rozwiązany, aktualizuje się, gdy nakazuje się przechowywać w nim informacje, nie ma już pokazywania komunikatu msqli, że pole jest puste, bo nie wstawiłeś do niego wartości, dobrze zastosowanie tego rozwiązania może działać na niektórych projekty zależy od struktury projektu.

ExploreTech
źródło
Rozwiązał mój błąd, zmieniając defaultatrybut kolumny z nonena NULL. Chyba że odpowiedzi na wysokie oceny! mój cPanel dawał mi odmowę dostępu do hostingu współdzielonego, gdy próbowałem zaktualizować zmienną sql_mode.
Rashid
0

rozwiązałem problem ze zmianą pliku my.ini znajdującego się w folderze danych. dla mysql 5.6 plik my.ini został przeniesiony do folderu danych, a nie do folderu instalacyjnego bin lub mysql.

sadik keskin
źródło
0

Myślę, że w tym przypadku kolumna z nazwą ma wartości null.

update try set name='abc' where created_by='def';
  
Sasindu
źródło