is there any way to change the master database collation in MsSql server 2008 to another collation, instead of reinstall it ?
You need to rebuild/recreate the master database as described here.
(Though that article also goes through the steps to change all user databases to the new collation you probably just need to follow the steps here)
Related
So for tests I am creating temporary docker SQL Server.
Unfortunately my production database uses some non standard collation.
So for tests I am creating test database with my custom collation. In next step using flyway I am migrating schema, but it seems like even database has my custom collation, flyway SQL statements inherit collation from SQL Server instance and I am getting collation collision exception.
Is there any way to force that every statement in database x should use database collation by default?
One important thing is that many of those SQLs are already on production, so I cannot add to them collation statement explicit.
is there any query that changes collation language not only database but also mssql server So that databases will be created in new collation language? Or do I have to establish database again?
Even if the link above is correct, I think it need some comments.
In order to change SERVER COLLATION you should rebuild system databases, and this means that after rebuild your instance will have only empty system databases.
All the information about databases previously attached to the instance will be lost. Of course you can first detach all the user databases and than re-attach them, or restore all the user databases from backups, but all your logins and linked servers will be lost.
You'll also find your msdb empty, so all your jobs, backup/restore history will be lost.
At this point may be you find it easier to re-install SQL Server with the correct collation since the result will be pretty the same: an instance with the correct collation and only empty system databases attached to it.
P.S. If you have already some databases with collation A and you change the server collation to collation B, after databases restore/re-attach they will preserve collation A. And some code using temporary tables may be break after this, it will fail with the errors "Could not resolve collation conflict"
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
There is a table in my database containing 100 columns. I want to create a trigger to audit the modification for every update operation.
What I can think is to create the update clause for all columns but they are all similar scripts. So is there any elegant way to do that?
Check Change Data Capture
Update
CDC provides tracking of all details of changes. Available since SQL Server 2008.
(Change data capture is available only on the Enterprise, Developer, and Evaluation editions of SQL Server.
Source: http://msdn.microsoft.com/en-us/library/bb522489.aspx)
More lightweight solution is Change Tracking (Sync Framework), the one code4life mentioned before, available since SQL Server 2005.
Update2:
Related questions (with a lot of sublinks):
History tables pros, cons and gotchas - using triggers, sproc or at application level
History tables pros, cons and gotchas - using triggers, sproc or at application level
Suggestions for implementing audit tables in SQL Server?
Suggestions for implementing audit tables in SQL Server?
Are soft deletes a good idea?
Are soft deletes a good idea?
How do I version my MS SQL database in SVN?
Versioning SQL Server database
Thomas LaRock. SQL Server Audit: Magic without a Wizard
http://www.simple-talk.com/sql/database-administration/sql-server-audit-magic-without-a-wizard/
There's this resource on MSDN which you might find helpful:
Tracking Changes in the Server Database (including SQL Server 2008)
I'm not sure if you're using SQL Server 2008 though.
Code generation?
Have you looked at the techniques which http://autoaudit.codeplex.com/ uses?
Theoretically, you can use 1 trigger and check COLUMNS_UPDATED() to know which columns has changed.
(not be tested)
See more here