This is the documentation for FishEye 3.2. View the latest version of

Unknown macro: {spacejump}

or visit the latest FishEye documentation home page.

It is possible to have files in your repository whose names differ only in case, e.g. Foo.java and foo.java. Hence, your database will need to use rules for comparing string values which recognise that upper and lower case letters are different, that is, the database should use 'case sensitive collation'.

If your database was originally configured to use case-insensitive and/or non-UTF8 collation, FishEye will display the following message at the bottom of your screen:

"Your database is not using a case sensitive UTF8 encoding for character fields."

The following sections provide instructions for changing your database collation for each database type supported by FishEye and Crucible.

On this page:

Related pages:

MySQL

Please take a backup of your database before changing its collation.

 

To change your collation to utf8_bin you need to change your database's default collation, but as this only affects newly created tables you will also need to change the collation on the table for which case sensitivity is critical.

Change your database's collation

Use the ALTER DATABASE command, as follows:

alter database character set utf8 collate utf8_bin;

Change collation for the CRU_STORED_PATH table

Use the ALTER TABLE command, as follows:

alter table cru_stored_path convert to character set utf8 collate utf8_bin;

Oracle

Oracle collation encoding must be configured when installing the database server. It cannot be configured on a per database level. When installing Oracle, you should select the AL32UTF8 encoding.

PostgreSQL

Please take a backup of your database before changing its collation.

 

If you have created your PostgreSQL database with the incorrect encoding, you will need to dump your database, drop it, create a new database with the correct encoding and reload your data.

You can do this using the standard database migration procedure – instead of migrating from HSQLDB to PostgreSQL, you migrate from a PostgreSQL database with the incorrect encoding to one created with the correct encoding.

SQL Server

Please take a backup of your database before changing its collation.

 

Unfortunately, changing the database collation for an existing SQL Server database (even using the ALTER DATABASE ... COLLATE... statement) does not change the collation for existing objects stored in the database. See http://blogs.msdn.com/b/qingsongyao/archive/2011/04/04/do-not-alter-database-collation-in-your-server.aspx for an explanation of this.

The recommended route for changing the collation for SQL Server is to migrate to a new database that has the correct collation configuration. You can do this using the standard database migration procedure – instead of migrating from HSQLDB to SQL Server, you migrate from a SQL Server database with the incorrect collation to one created with the correct collation.

The correct collation to use when you create the new SQL Server database is Latin1_General_CS_AS.

  • No labels

 

 

 Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.