2

FogBugz encountered an error upgrading your FogBugz database and rolled back all changes. The error is:

Wasabi.Runtime.WasabiException (0x80004005): Specified key was too long; max key length is 1000 bytes SQL: CREATE INDEX IX_PersonCompound ON Person (ixPerson, sFullName, sPhone, sEmail, fNotify) MySql.Data.MySqlClient.MySqlException: Specified key was too long; max key length is 1000 bytes at MySql.Data.MySqlClient.MySqlStream.OpenPacket () [0x00000] at MySql.Data.MySqlClient.NativeDriver.ReadResult (System.UInt64& affectedRows, System.Int64& lastInsertId) [0x00000] at MySql.Data.MySqlClient.MySqlDataReader.GetResultSet () [0x00000] at MySql.Data.MySqlClient.MySqlDataReader.NextResult () [0x00000] at Wasabi.Runtime.Error.Raise (Int32 number, System.String source, System.String description, System.String helpfile, Nullable`1 helpcontext) [0x00000] at FogCreek.FogBugz.CSQLRunner.RunSQL (System.String sCmd) [0x00000] at FogCreek.FogBugz.CIndex.Create (System.String sTableName) [0x00000] at FogCreek.FogBugz.CTable.UpdateDB (FogCreek.FogBugz.CDispatcher dispatch) [0x00000] at (wrapper remoting-invoke-with-check) FogCreek.FogBugz.CTable:UpdateDB (FogCreek.FogBugz.CDispatcher) at FogCreek.FogBugz.CSchema.UpdateDB (Int32 OldVersion, Boolean bForce) [0x00000] at FogCreek.FogBugz.__Global.UpgradeDatabaseVersion (Boolean fForce) [0x00000] at FogCreek.FogBugz.__Global.UpgradeWithRollback (Boolean fForce) [0x00000]

flag

3 Answers

1

The problem was the Fogbugz database was using a default-character-set of utf8 which takes more than 1 byte per character.

Solution was to dump the database and change all definitions of utf8 to latin1.

sed -e 's/utf8/latin1/g' -i ./NAMEOFDUMPEDDATA

recreate a new database and load the dumped data. then retry the database upgrade.

This was a v6 to v7 upgrade on SLES 10.1, mysql 5.0.26

link|flag
(This is actually Stan's answer, I'm just posting it for him) – Jude Allred Jan 14 2010 at 15:30
1

Changing sEmail to varchar(200) before the upgrade doesn't help here (upgrading 6.1.46 to 7.1.10), maybe the db upgrade first changes the column back to varchar(249) before trying to create the index.

Doing this before the upgrade did work for me:

ALTER TABLE Person CONVERT TO CHARACTER SET latin1;
link|flag
0

Another solution is to perform this command:

ALTER TABLE Person MODIFY sEmail VARCHAR(200);

And then retry the database upgrade.

link|flag

Your Answer

Not the answer you're looking for? Browse other questions tagged or ask your own question.