I've installed Umbraco into my ASP.NET MVC project and in installation asked for database information and generated catalog successfully.
I'm using a shared server which has a instance level collation that Turkish_CI_AS. While I tried some configuration I've encountered an error:
In Umbraco, while tried to listing users the exception I've encountered.
And so I've listed table's collation settings so I've discovered except nvarchar / varchar columns, all the columns' collations are NULL.
So in umbracoUsers (which is the users' table has a column 'id')
Information of users' table
I've also inspected Umbraco DB generator script via their source codes and there is no word like 'collation' in all scripts.
How to alter ALL column collations which are NULL to instance default collation?
Any ideas will be appreciated. Please do not hesitate :)
Regards.
I've found a workaround this issue. For some reason I don't know but if you define instance / database level collation Turkish_CI_AS, this corrupt column name case-insensitivity. If you really have to use Turkish_CI_AS as collation (just like me) create database with this collation (so let the tables be with this collation) then alter DATABASE's collation with Latin1_General_100_CI_AS. (maybe other collation will also work)
This workaround provides that tables' collations are still Turkish_CI_AS and column-name based case sensitivity problem will be solved.
Thanks for your answers.
Related
I am in the process of installing a database onto a client's server. The collation that is set on the server is SQL_Latin1_General_CP1_CS_AS, so it is case-sensitive.
The database that I am installing uses collation level SQL_Latin1_General_CP1_CI_AS, so it is case-insensitive.
The issue I am running into now is that all variables in stored procedures must be case sensitive or else it will throw an error.
Example:
Declare #Dimension varchar(45)
Set #dimension = 'Test'
Error:
Must declare the scalar variable "#dimension".
The lowercase "d" in the #dimension variable is causing it to be recognized as a completely different variable.
Is there a setting in the database that I can update to ignore the Server's collation?
Note: I received permission to update the collation at the server level as it is a test server. However, it is a more involved process. I am looking for a way to get around this without having to go through the steps found in this link:
Make sure you have all the information or scripts needed to re-create your user databases and all the objects in them.
Export all your data using a tool such as the bcp Utility. For more information, see Bulk Import and Export of Data (SQL Server).
Drop all the user databases.
Rebuild the master database specifying the new collation in the SQLCOLLATION property of the setup command. For example:
Setup /QUIET /ACTION=REBUILDDATABASE /INSTANCENAME=InstanceName
/SQLSYSADMINACCOUNTS=accounts /[ SAPWD= StrongPassword ]
/SQLCOLLATION=CollationName
Create all the databases and all the objects in them.
Import all your data.
Thank you
To work around this, set your database as Partially Contained. This will give you Contained Database Collation, which provides:
Since a design objective of contained databases is to make them
self-contained, the dependence on the instance and tempdb collations
must be severed. To do this, contained databases introduce the concept
of the catalog collation. The catalog collation is used for system
metadata and transient objects.
In a contained database, the catalog collation
Latin1_General_100_CI_AS_WS_KS_SC. This collation is the same for all
contained databases on all instances of SQL Server and cannot be
changed.
As per experience would be a faster way is to backup all databases then re-install the sql-server with the correct collation, then restore all databases. Might be a manual thing for permissions but there can be other options.
When a database is created from our application, it takes the default Collation. we don't want to pass the collation in the create database script.
A client has a collation set on the instance level that is Case Sensitive. So the database created for our application is in that collation which is something we don't want.
Can they change the collation on the instance level so the database that gets created will have the desired collation and they can change it back to whatever they want? How do we do this on the instance level?
Thanks for your time!
So the problem is that the database is not created by a script run in, say, SQL Management Studio, but a script launched from within the application.
As noted in the comments and another answers changing the server collation is possible but hairy, the best option in a case like this is creating the database empty, changing the collation (either with ALTER DATABASE or from Management Studio), and then create the rest of the database.
This would require changing the application, but only the creation of the database itself since the tables will take the collation of the database, not the server collation (and you can do it in a way that works for every client, check if the database exists and that case skip DB creation and proceed with the rest of objects).
As a final warning, note that having a DB with a collation different of the server collation would mean than the DB has a different collation than the tempdb, so if you use temporal tables you would have problems if you have WHERE's or JOIN's mixing temporal and regular tables. For example, supposing that SerialNumber is a char column, this query will fail with a collation error:
SELECT *
FROM Products
JOIN #TempTable ON #TempTable.SerialNumber=Products.SerialNumber
If that case you will have to modify the application and change the queries to something like this:
SELECT *
FROM Products
JOIN #TempTable ON #TempTable.SerialNumber=Products.SerialNumber COLLATE database_default
You can configure the instance collation which would require dropping the databases before changing it. Here is a link to setting or changing the Server Collation.
You can also do this on a database level. Here is information on setting or changing collation on the database level.
You may also want to read the collation clause which can also be applied to tables, columns, and casting expressions among additional options.
Dear all, Currently I am just researching how I could handle the change of the collation on the database.
Somebody made an unusual decision to create accent sensitive database for global use... but I am on the way to handle this!
REASON: of changing the collation is that database contains data collected from different countries and as we all know some of cultures have their own letters.
With the respect for the customers, our organization would like to have Accent Insensitive database. That will allow users to request data from the server without any limitations using local characters.
As far as I have find out, there may be an option to drop constraints and etc. change collation and then just to bring everything back. In this case I am afraid if this would be enough to affect already existing data (columns).
Another way, I have found an article in Collation change on 2005 and 2008 server. However, this does not include the 2012 server.
Also I am taking the complexity of this example into consideration as well.
I believe that I am not in an easy phase. But I am hoping to get few advises what would be the best and safest way to handle this.
Thank you for your concerns and assistance.
UPDATE let me add what architecture do we have: The complete system contains 4 databases and more than 1.000 tables in total. So my expectations is that not all of the possible ways may work in an optimal way.
me too i had to deal with a similar issue because of a different reason: ancient databases with an old SQL collation installed ages ago on a SQL6.5 server that has been inplace upgraded for each version from sql 7 to sql 2005 and now should be updated to sql 2012.
why all these inplace upgrades? because the actual collation was the server collation and was so old that is not available during then install process of a recent version (2000+) of sql server...
i decided to drop all that old rubbish so i had to find a way that allowed me to move to a new installation with a windows collation.
i had to exclude the data migration (create a new database and import data) because of the lack of documentation and the huge number of customizations, triggers, hidden rules and so on.
the solution i used (the order matters):
disable automatic statistics generation
script the creation of all foreign keys and then drop them
script unique and primary indexes and then drop them
script all remaining indexes and then drop them
script custom statistics and then drop them
script CHECK and DEFAULT constraints and then drop them
now you can run the ALTER commands needed to change the collation of the columns and change the collation of the database itself.
when done repeat the above in reverse order to rebuild all the needed objects.
it happens that if the database is so old as is mine you may incur in something funny like existing foreign key that references fields with different datatypes.
Changing collation of all existing columns is a real pain. I suggest a side-by-side migration rather than alter each column individually. Create a new database with the desired collation containing only empty tables. Copy data from the old db to the new one using INSERT...SELECT (or the ETL tool of your choice), and then create constraints, indexes, and other database objects.
Consider upvoting the Make it easy to change collation on a database SQL Server feature request.
There are a number of complicated solutions on the internet for inplace collation changes but the simplest (and safest) way we have found is to script out the database, alter the script to create a new db with the collation set at the start and then import the data to the new database.
We achieve this using MS SQL Server 2012 Management Studio in the following way:
Script out all database objects with Tasks -> Generate Scripts -> Script entire Database and all Database objects
Alter the script with the following 2 changes and then run it to create a new database:
a) Change DB name to MY-NEW-DB
b) Under the CREATE DATABASE statement add: ALTER DATABASE [MY-NEW-DB] collate Latin1_General_CS_AS
If desired, use a tool like RG SQL Compare to compare the old and new database to verify all indexes, constraints, types etc were the same and collation on relevant columns only was changed.
Run Tasks->Import Data ensuring 'Enable Identity Insert' checked. All data transferred to the new case sensitive database correctly.
Run DBCC CHECKDB if you wish to check consistency
I have a two big programs that connect to a SQL Server 2005 database.
Now we will migrate to a new server with SQL Server 2008.. the programs don't work anymore when connected to the new server, the cause is that in all the queries in the programs only table names are used, and they are not dbo tables.. so SQL Server 2008 doesn't recognise them, unless I use the schema name before the table name...
It is very very difficult for me to change all the queries in the two programs to add the schema name before the tables names.
I read in this forum that if I specify the default schema the problem will be solved.. but it haven't been solved though.
The only solution that seems to be working is when I changed the schema of the table to dbo.. but I am not sure if this action will be OK or will it cause some other problems related to this modification?
Is there any better solution?
Will changing the schema of the tables cause me other kind of problems?
Many thanks in advance
Default schemea will work for you. What are the issue with this approach?
Change schema name will cause a big issue and not advisable. Where and how much schema name change?(just think).
You just set a default schema with only one procedure first and check, if this is ok. then change the whole database schema.
https://dba.stackexchange.com/questions/21158/net-sql-server-authentication-schema-issue
In sql server 2005, how do I change the "schema" of a table without losing any data?
Change Schema Name Of Table In SQL
Best practice for SQL Server 2008 schema change
Transferring data from one SQL server to another but when Schema is compared and syncronised the following error is received. We are using redgate SQL compare to complete.
Cannot resolve collation conflict for equal to operation
Base SQL server is SQL_Latin1_General_CP1_CI_AS and the destination server is Latin1_General_CI_AS
SQL Compare has an option to ignore collations. Look under the tab "options" in your compare project configuration.
is you problem with the SQL Compare utlity, or a worry that different server collations will lead to problems?
You could change the collation of the destination server to match the Base server
If that is not possible, then make the Collation of the databases on each server match, and then your only real problem is likely to be any temporary tables which you create (they will have a default collation matching the server / TEMPDB), and so long as you explicitly create the temporary table (i.e. don't create it using SELECT * INTO #TEMP FROM MyTable) and explicitly assign a collation to any varchar/text columns you should be OK
The way I overcome this is to generate the scripts via SQL Compare and then strip out (or replace) the Collation specific code. This is relatively fast and easy to do, and finally I manually apply the scripts to the destination server/ database.
Sounds like the collation settings for the server are different.
How are you transferring the data, do you perform a database restore on your new platform?
Either way, you need to ensure that the same collation is used on your new environment as is currently in place in your source environment.
Hope this makes sense, let me know if you need further assistance.
"Ignore collations" is definitely not going to work, for the reason stated above. The problem happens when migrating objects like views and stored procedures that use JOIN clauses on text fields that have differing collations.
If someone changes the default collation on the server and the column on the other side of the JOIN uses a specific collation, you've caused this issue. And it would happen in SQL Compare as well as if you just manually scripted the object in SSMS and moved it yourself.
There are two roads to fixing it - you could specify a COLLATE clause on the join and explicitly state the collation you want to use, or you could change the destination database default collation to match the source.
I'm afraid there is no SQL Compare "magic bullet" to solve this.