Try activating debug mode in /application/config/config.php and see if you get a more detailed error.

Yes !

SQLSTATE[42000]: Syntax error or access violation: 1071 Specified key was too long; max key length is 1000 bytes. The SQL statement executed was: ALTER TABLE lime_tokens_16277_20111114 CHANGE lastname lastname varchar(150)

Is it useful ?

Yes, probably there is a non-standard key on that table which includes the 'lastname' field or you probably edited a field length manually. Use a table editor to inspect the related table and maby rememoce it. The table name looks non-standard, too.

Hum here is a CREATE TABLE dump from the DB:
CREATE TABLE lime_tokens_16277_20111114 (
tid int(11) NOT NULL AUTO_INCREMENT,
firstname varchar(150) COLLATE utf8_unicode_ci DEFAULT NULL,
lastname varchar(40) COLLATE utf8_unicode_ci DEFAULT NULL,
email varchar(254) COLLATE utf8_unicode_ci DEFAULT NULL,
emailstatus text COLLATE utf8_unicode_ci,
token varchar(36) COLLATE utf8_unicode_ci DEFAULT NULL,
language varchar(25) COLLATE utf8_unicode_ci DEFAULT NULL,
sent varchar(17) COLLATE utf8_unicode_ci DEFAULT 'N',
remindersent varchar(17) COLLATE utf8_unicode_ci DEFAULT 'N',
remindercount int(11) DEFAULT '0',
completed varchar(17) COLLATE utf8_unicode_ci DEFAULT 'N',
validfrom datetime DEFAULT NULL,
validuntil datetime DEFAULT NULL,
mpid int(11) DEFAULT NULL,
usesleft int(11) NOT NULL DEFAULT '1',
participant_id varchar(50) COLLATE utf8_unicode_ci DEFAULT NULL,
blacklisted varchar(17) COLLATE utf8_unicode_ci DEFAULT NULL,
PRIMARY KEY (tid),
KEY lime_tokens_16277_idx (token),
KEY idx_lime_tokens_16277_efl (email(120),firstname,lastname)
) ENGINE=MyISAM AUTO_INCREMENT=61 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;
/!40101 SET character_set_client = @saved_cs_client /;

So, there is a KEY with lastname, but I don't know/understand what is wrong. If the field has been manualy edited, it's not me and I don't know who is it and why...

What could I do ? It seems there are many others tables like this one in the DB :(

Me again..

I have a question: is it Limesurvey himself that creates indexes ? like that kind of names: 'idx_lime_tokens_26787_efl'
Or it is possibly created by a survey developper ?

Is it bad if I delete all of the indexes for concerned tables but keep the tables ?

There is no harm done if you delete the _efl indexes - they will be re-created by the update script.

I just checked the source - LimeSurvey actually tries to delete the index beforehand, but since your table has a nonstandard-naming it cannot properly find out the correct index name and so the deletion fails.
Anyway, this is not a LimeSurvey bug since someone manualyl renamed a table in the database.