2016-08-04 2 views
1

Я пытаюсь отладить проблему с помощью инструкции обновления. Он не работает в нашем приложении Java в нашей среде разработчиков, но преуспевает в локальных средах. При запуске вручную он работает правильно в локальных средах, но не в dev. Определение таблицы в обеих средах одинаково, за исключением текущего значения auto_increment.Данные Varchar MySQL усекаются для столбца name_last в строке 1

Ошибка:

Error Code: 1265. Data truncated for column 'name_last' at row 1 0.062 sec 

Вот запрос:

update party set 
master_id = 0, 
name_last = 'aaa', 
name_first = 'bbb333333333333333333333333333333333333333333333333333444444', 
name_middle = 'ccc555555555555555555555555555555555555555555556666666666666', 
name_suf = null, 
business_name = null, 
business= 0, 
alias_of_id= null, 
is_alias= 0, 
updated_user = 3, 
active = 1 
where 
party_id = 20986 

Вот определение таблицы

CREATE TABLE `party` (
    `party_id` int(10) unsigned NOT NULL AUTO_INCREMENT, 
    `master_id` int(10) unsigned DEFAULT NULL, 
    `name_first` varchar(60) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `name_last` varchar(60) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `name_middle` varchar(60) COLLATE utf8_unicode_ci DEFAULT NULL, 
    `name_suf` varchar(45) COLLATE utf8_unicode_ci DEFAULT '', 
    `business_name` varchar(255) COLLATE utf8_unicode_ci DEFAULT '', 
    `is_alias` bit(1) DEFAULT b'0', 
    `alias_of_id` int(10) unsigned DEFAULT NULL, 
    `business` bit(1) NOT NULL DEFAULT b'0', 
    `active` bit(1) NOT NULL DEFAULT b'1', 
    `updated_ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP, 
    `created_ts` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP, 
    `updated_user` int(10) unsigned NOT NULL, 
    `created_user` int(10) unsigned NOT NULL, 
    `name_pre` varchar(5) COLLATE utf8_unicode_ci DEFAULT NULL, 
    PRIMARY KEY (`party_id`), 
    KEY `IX_Party_Name` (`name_first`,`name_last`,`name_middle`) 
) ENGINE=InnoDB AUTO_INCREMENT=20988 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci; 
+0

'ВЫБРАТЬ @@ VERSION, @@ SQL_MODE; '. Сравните. –

+0

Также проверьте триггеры. Запрос не имеет очевидной ошибки, поэтому триггер может выбросить это. –

+0

Майкл, спасибо. У нас есть триггер, который копирует из таблицы вечеринок в таблицу party_history. Столбцы в таблице party_history являются только varchar (45), поэтому, похоже, это источник проблемы. Удивительно, что он преуспевает в локальной среде, которая имеет ту же проблему определения таблицы для таблицы истории. –

ответ

0

данных Усеченный происходит тогда, когда размер поля меньше, чем значение данных будет вставлено: например,

вашего поля "name_last VARCHAR (10)", а затем вставить значение более 10 символов возврата ошибок в данных усеченных .:

увидеть эту ссылку ниже для получения дополнительной информации:

https://en.wikipedia.org/wiki/Data_truncation

+0

Согласен. Однако, как видно из приведенного выше оператора, это не удалось, значение, которое я пытаюсь сохранить в столбце name_last, составляет всего 3 символа. Столбец имеет размер 60 символов. Таким образом, эта ситуация, похоже, не применяется. –

Смежные вопросы