Timeline for Collation conflict ... Could not use dbo.sysdac_instances
Current License: CC BY-SA 3.0
7 events
| when toggle format | what | by | license | comment | |
|---|---|---|---|---|---|
| Apr 13, 2017 at 12:42 | history | edited | CommunityBot |
replaced http://dba.stackexchange.com/ with https://dba.stackexchange.com/
|
|
| Apr 1, 2016 at 20:05 | comment | added | Solomon Rutzky |
@YaHozna While DEFAULT_DATABASE is a very handy option in many cases, I would not recommend it for your situation. The msdb database has a binary collation while the server (i.e. other system DBs) have a case-insensitive Collation. By using DEFAULT_DATABASE you are making the operation use the binary Collation while most other operations against server meta-data will be case-insensitive. I would think it better to prefer the server's default Collation, which is now Latin1_General_CI_AS.
|
|
| Apr 1, 2016 at 8:59 | comment | added | YaHozna | I've certainly managed to amend a couple of queries that were throwing the same collation conflicts by using COLLATE DEFAULT_DATABASE however I was uncertain about amending a system view, although srutzky has mentioned that below as being the lesser of the evils. | |
| Mar 31, 2016 at 17:41 | comment | added | RLF | @MaxVernon - I understood the CATALOG_DEFAULT was used to overcome the metadata collation problem. Appreciate any clarification you have. But I certainly agree that having the same collation is the best answer. | |
| Mar 31, 2016 at 17:32 | history | edited | RLF | CC BY-SA 3.0 |
Clarify metadata collation
|
| Mar 31, 2016 at 17:28 | comment | added | Hannah Vernon♦ | How does this apply to a system view, whose definition cannot be altered? | |
| Mar 31, 2016 at 17:25 | history | answered | RLF | CC BY-SA 3.0 |