When setting up a new schedule if too long a schedule name is entered scheduled backups will not run.

The following error will be created on Cron run:

PDOException: SQLSTATE[22001]: String data, right truncated: 1406 Data too long for column 'name' at row 1: INSERT INTO {variable} (name, value) VALUES (:db_insert_placeholder_0, :db_insert_placeholder_1); Array ( [:db_insert_placeholder_0] => backup_migrate_schedule_last_run_smart_schedule_keep_hourly_backups_for_the_past_24_hours_daily_backups_for_the_past_30_days_and_weekly_backups_forever [:db_insert_placeholder_1] => i:1457615183; ) in variable_set() (line 991 of /Applications/XAMPP/xamppfiles/htdocs/j2235_stackhouse_portal_new/includes/bootstrap.inc).

Suggested solution, limiting the allowed characters in the schedule name feild.

Currently if the issue is triggered, there is no way of deleting a schedule, therefore the only workaround is to disable then uninstall the module, then reinable and create a schedule with a shorter name,

Comments

paultrotter50 created an issue. See original summary.

DamienMcKenna’s picture

Version: 7.x-3.1 » 7.x-3.x-dev
Component: Code » User interface

You could also delete the record from the 'backup_migrate_schedules' table. But yeah, there's a bug in that.

BrankoC’s picture

In B&M, #maxlength only seems to be set on machine_name fields of crud items. Presumably, any form field could lead to problems if it contains more characters than can be stored in the corresponding database field, and this in turn may be a function of the database engine being used.

An example of the latter is described in Profile Filter field - hitting 64Kb limit, where a textfield is assigned a 'medium' size: the actual size differs per database engine and is described by getFieldTypeMap() (and may even differ then, depending on the text encoding that was chosen).

I wonder if this shouldn't be a #wontfix. On the one hand validating field lengths well takes a lot of time, and on the other hand, users should realise that they shouldn't put a novel inside a Name field.

Reporter, why did you need a name of 256+ characters?

DamienMcKenna’s picture

IMHO the bug is allowing machine names to be that long in the first place, they should truncate to a much shorter string.