question

It's not ideal for a database to have a different collation than the server but it's not necessarily a show stopper. I've seen several cases of this running quite happily, although cross-database queries will have to explicitly specify the collation in string comparison expressions in WHERE clauses and JOINs. Putting the file on a different drive won't change this issue at all. There's a bit more detail here: http://www.brentozar.com/blitz/database-server-collation-mismatch/

There is no inherent danger in having different collations across databases. You can even have different collations across various columns in the same table. And in fact, if you look at any of the system catalog views (`sys.tables`, `sys.objects`, `sys.columns`, and so on) you will find that they have several collations across the columns, and for various reasons.

The issues you may potentially run into depend on what you are doing in your queries, and if the database is a contained database.

1. A common issue is that `[tempdb]` default collation matches the server collation, which will now not match the new DB's collation. If code in the new DB creates a local or global temp table and doesn't specify the `COLLATE` clause, the fields will take on the collation of `[tempdb]`. If you run into collation mismatch errors, you need to specify `COLLATE DATABASE_DEFAULT`. This does not apply to Table Variables as those take on the collation of the current database when they are declared. This applies slightly differently to contained databases.
2. If you are using a Contained Database then the rules change slightly: the default collation for string fields in temp tables is taken from the current database, hence is inherently already using `DATABASE_DEFAULT`. For more info, please see Contained Database Collations on MSDN.
3. If you have cross-database queries that compare string fields between tables in both DBs and the column collations between the fields do not match, then you will have essentially the same scenario as noted with temp tables above. The difference here is that these tables already exist so you are not going to alter either column to change its collation. But the fix is still essentially the same: specify `COLLATE DATABASE_DEFAULT` or even `COLLATE {desired_collation_name}` on the field(s) in the query with the non-matching collation. You just need to decide which collation should be preferred between the two in order to determine which field will get the `COLLATE` clause.
4. If you run the same code in both DBs, you might could see variations in how certain statements behave since string literals and local variables take on the collation of the DB where the code is defined (or being run if an ad hoc query). So:
   
   

   SET @LocalVar NVARCHAR(50);
   SELECT @LocalVar = TOP (1) something
   FROM   some table;
   IF (@LocalVar = N'string literal')
   BEGIN
       some statements;
   END;

   
   could potential behave differently when run in both DBs, even if the same initial value of the same collation was used to set the value of `@LocalVar`. This is not a huge concern, just something to be aware of. Please see the documentation page for Collation Precedence for more details.

5. Comparing string values in local tables against system catalog views. Some fields in some catalog views take on the local DBs collation, especially related to things that you name that reside in that DB: tables, columns, indexes, etc. So, `sys.tables.name` will have the local DBs collation. Again, just something to be aware of.

The question about where to physical store the data file(s) for the new DB is entirely irrelevant to this Question about collations.