I kept getting this error thrown at me every time I tried to run an import with the latest version of 7-dev:

<em class="placeholder">PDOException</em>: SQLSTATE[01000]: Warning: 1265 Data truncated for column &#039;starttime&#039; at row 1: INSERT INTO {migrate_log} (machine_name, process_type, starttime, initialHighwater) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array
(
    [:db_insert_placeholder_0] =&gt; Glossary
    [:db_insert_placeholder_1] =&gt; 1
    [:db_insert_placeholder_2] =&gt; 1306968498590
    [:db_insert_placeholder_3] =&gt; 
)
 in <em class="placeholder">MigrationBase-&gt;beginProcess()</em> (line <em class="placeholder">700</em> of <em class="placeholder">/usr/local/apache/staging.gina.net/htdocs/northpoint_drupal/sites/all/modules/contrib/migrate/includes/base.inc</em>).WD php: PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'starttime' at row 1: INSERT INTO {migrate_log} (machine_name, process_type, starttime, initialHighwater) VALUES      [error]

I was able to fix this error by removing the reference to microtime() like so:

693       $this->logID = db_insert('migrate_log')
694                      ->fields(array(
695                        'machine_name' => $this->machineName,
696                        'process_type' => $newStatus,
697                        'starttime' => REQUEST_TIME,
698                        'initialHighwater' => $this->getHighwater(),
699                        ))

Can anyone else confirm this error?

Comments

chromix’s picture

chromix CreditAttribution: chromix commented

The fix should also be applied to line 730, basically anywhere where microtime(TRUE) * 1000 is used.

chromix’s picture

chromix CreditAttribution: chromix commented

I realize now this doesn't actually result in a useable date, but does anyone know why MySQL would complain about this?

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Murphysboro, IL, USA
CreditAttribution: mikeryan commented
Status: Active » Postponed (maintainer needs more info)

For me, starttime and endtime are defined as bigints with a length of 20 in MySQL - how is it for you?

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Murphysboro, IL, USA
CreditAttribution: mikeryan commented

From http://dev.mysql.com/doc/refman/5.1/en/numeric-type-overview.html:

BIGINT[(M)] [UNSIGNED] [ZEROFILL]

A large integer. The signed range is -9223372036854775808 to 9223372036854775807. The unsigned range is 0 to 18446744073709551615.

Seems like that should be big enough:-).

mikeryan’s picture

mikeryan
he/him
Primary language English
Location Murphysboro, IL, USA
CreditAttribution: mikeryan commented
Status: Postponed (maintainer needs more info) » Closed (cannot reproduce)

No other reports of this, seems like something funky in that particular database.

chromix’s picture

chromix CreditAttribution: chromix commented

Sorry to reopen, but the db I'm working with is decidedly funky. Just a quick response here, though, I did a desc on the log table and this is what i got:

+------------------+---------------------+------+-----+---------+----------------+
| Field            | Type                | Null | Key | Default | Extra          |
+------------------+---------------------+------+-----+---------+----------------+
| mlid             | int(10) unsigned    | NO   | PRI | NULL    | auto_increment | 
| machine_name     | varchar(255)        | NO   |     |         |                | 
| process_type     | tinyint(3) unsigned | NO   |     |         |                | 
| starttime        | bigint(20) unsigned | NO   |     |         |                | 
| endtime          | bigint(20) unsigned | YES  |     | NULL    |                | 
| initialhighwater | varchar(255)        | NO   |     |         |                | 
| finalhighwater   | varchar(255)        | YES  |     | NULL    |                | 
| numprocessed     | int(10) unsigned    | YES  |     | NULL    |                | 
+------------------+---------------------+------+-----+---------+----------------+

Seems normal, no? And yet I'm still getting these bizarre errors whenever I try to run a migration. No idea why, still. Here's the complete error for anyone interested:

An AJAX HTTP error occurred. HTTP Result Code: 500 Debugging information follows. Path: /batch?id=17&op=do StatusText: Service unavailable (with message) ResponseText: PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'starttime' at row 1: INSERT INTO {migrate_log} (machine_name, process_type, starttime, initialHighwater) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => TimelineEvent [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => 1308279989100 [:db_insert_placeholder_3] => ) in MigrationBase->beginProcess() (line 702 of sites/all/modules/contrib/migrate/includes/base.inc).PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'starttime' at row 1: INSERT INTO {migrate_log} (machine_name, process_type, starttime, initialHighwater) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3); Array ( [:db_insert_placeholder_0] => TimelineEvent [:db_insert_placeholder_1] => 2 [:db_insert_placeholder_2] => 1308279989100 [:db_insert_placeholder_3] => ) in MigrationBase->beginProcess() (line 702 of sites/all/modules/contrib/migrate/includes/base.inc).

Just for the sake of argument I adjusted the column to be bigint(28) unsigned. This didn't solve the problem, so apparently MySQL is finding this problem elsewhere. Maybe in another table that references it? I found this article somewhat interesting:

http://www.mysqlperformanceblog.com/2009/02/07/beware-of-mysql-data-trun...

Maybe last_imported in the migrate_map_ tables is somehow referencing the starttime/endtime columns? I notice last_imported is only an int(10), so I could see that causing some errors if there's a direct reference between the two columns. That's my only guess, though. I think the best way around this is to see if I can just turn off STRICT_ALL_TABLES but I'm sure I'm not the only one with STRICT_ALL_TABLES set on my D7 install... right?

ArialBlack’s picture

ArialBlack CreditAttribution: ArialBlack commented

i had error
PDOException: SQLSTATE[01000]: Warning: 1265 Data truncated for column 'field_lavatory_value' at row 1: INSERT INTO {field_data_field_lavatory} (entity_type, entity_id, revision_id, bundle, delta, language, field_lavatory_value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1, :db_insert_placeholder_2, :db_insert_placeholder_3, :db_insert_placeholder_4, :db_insert_placeholder_5, :db_insert_placeholder_6); Array ( [:db_insert_placeholder_0] => node [:db_insert_placeholder_1] => 393 [:db_insert_placeholder_2] => 393 [:db_insert_placeholder_3] => pa_apartments [:db_insert_placeholder_4] => 0 [:db_insert_placeholder_5] => und [:db_insert_placeholder_6] => ) in field_sql_storage_field_storage_write() (line 448 of /home/eventdes/wwg.com.ua/7h/modules/field/modules/field_sql_storage/field_sql_storage.module).