I cannot alter database tempdb because it is a system database.
I installed a fresh SQL Server 2008 R2 on my system, by default it got the collation as Latin1_General_C1_Ai_WS. But my Database Collation is SQL_Latin1_General_C1_Ai_AS.
So, I am getting Collation Error in all the places whereever I have used temp tables.
All temp (#) tables are getting created with the default collate Latin1_General_C1_Ai_WS, so wherever I have used temp table, I am getting an error.
I tried reconfiguring but it didn't work.
Because of this I am manually adding collate in all temp tables.
Please Help.... Thank You!
You either do what you say you are doing, forcing the temp tables to have the same collation as your database, or you change the default collation of the database. But this latter is complicated and takes quite a bit of work. See here for a step by step.
I'd go ahead and change the default collation and actual collation of your database, using those steps, if I were you. More work now, but will save you tons of headaches later.
Related
So I have two SQL Servers at the moment, both 2012 and both running separate systems.
One of these servers runs on a collation of latin1_general_bin and the other runs with latin1_general_ci_as, ideally I'd like to shut one of these servers off and move all the systems to one place.
I know this can be done technically, however I was wondering if this was a good idea? Will I be causing myself more problems down the line?
Both databases are transactional based and are defined by external parties so cannot have their collation changed. If I were as to do this, would it be better to have the server collation set as latin1_general_bin or latin1_general_ci_as? I'm thinking that the case sensitive option would be better as queries would still run against case insensitive databases whilst case insensitive queries would need to be carefully managed
There should be no problem using databases with different collations on one server. One of our external vendors also provides a database with different collation and this has been working without issues since SQL Server 2000. However, you will have to explicitly specify the collation (or use collation database_default when you want to join tables from the different databases. From my own experience, that can have quite a performance impact. You also need to be careful when using SELECT INTO when creating a new table as this can result in mixed collation in a database or table.
Yes, SQL Server keeps the collation neatly separated with the databases. But there is a big flaw, which caused severe problems with one of our customers:
The temp table (CREATE TABLE #Tbl ...) uses the server's default collation if you do not specify the collation explicitly.
In one of our projects, especially with quite old stored Procedures created with SQL Server 2000, there was heavy usage of temp tables to store intermediate results.
The customer ran into crazy errors and it took a hell of a lot of time to track this down. He did not want to change his server (due to other databases running there). So we changed the database to his collation. After this some of our upgrade scripts did not run anymore... It ended with all databases changed to the same collation and the installation of another instance of SQL Server.
Which collation is the best for you? I don't know... This depends on your needs. Are you dealing with diacritic characters a lot (look at "_as"), do you want "test" to be equal with "TeSt" (look at "_ci")
We have an old SQL Server database with case sensitive collation, but our newer application code expects column and table names to be case insensitive.
So, we are trying to convert the database so that the column and table names will be case insensitive.
The solution so far is to create an empty DB with case insensitive collation, then generating scripts from the old database to recreate the schema in the new database (using SQL Server Studio), then exporting the data from the old database into the new database.
This almost works, but the old instance allowed for a couple of rows of data that are identical when ignoring case sensitivity and we have a unique constraint violation.
Is there a simple way to allow for SQL references to table and column names to be insensitive while column data is treated as sensitive still (without having to modify the columns individually with separate collations)?
When you create a database, the system tables that hold the object names get the collation of the database -- here you want an insensitive collation. If you then want all your data to be case sensitive still, change the database's default collation, then run your scripts.
Changing the collation will not change the collation of already created objects (including the system tables) but it will affect subsequent objects.
Without changing the column collation at all, you can override it on individual queries, for example WHERE A = 'Hi' COLLATE Latin1_General_CS_AI, but this is inefficient because it will prevent the use of indexes for seeking (as conversions are required). It's not possible to define a constraint with a collation override -- you'd have to get complicated and define it on a computed column with a separate collation.
I have several databases on a SQL Server instance. I have certain queries that extract information simultaneously these databases. It turns out that after restoring of one of the databases (but that came from another server), these queries gives a COLLATION error. I realized then that this "new" database has a different COLLATION, so that forces me to use the COLLATE for each respective column in these queries. The problem is I have many queries and it would not be practical to make this change on all. I have way to change Database COLLATION, as well as all needed columns? I already tried to change the Database but it seems that columns COLLATION remain the same...
If the collation for individual columns are not set to Database default, you should change them one by one.
I have one question, I was trying to find more information on the internet but, I'm still not sure about it.
If I have a SQL Server instance with the following default Collation example "Modern_Spanish_CI_AS" and I also have a restored databse with different collation example "Latin1_General_CI_AS".
What collation SQL Server will use? by default the Modern_Spanish... or it will use from database Latin1_General?
In the follwing link explains something about it
Setting and Changing the Server Collation
Thanks!
It will use the Latin1_General_CI_AS collation, as that's what's set in the database itself.
For clarification, whatever's set in the database will override the "default" collation for the server. The default collation is basically only used when you create a brand new database.
Changing the default collation at the server level has no effect on existing databases, you would have to change each collation individually, though that in itself will probably cause you cascading issues with any other database level objects you've created, such as stored procedures, constraints and even any dynamic SQL you're executing against the database from 3rd party applications.
SQL Server collations can be set at various levels: server, database, column, expession. If you do not set a collation at a lower level it is inherited from the level above. E.g. when creating a database the database collation will be the server's collation unless you explicitly set a collation for the DB.
And many collations will work together fine. Occasionally there can be difficulties, often of the nature of sort order being unexpected. I do not know for sure but I would expect the 2 you specify to be compatible.
So yes, your DB will (almost certainly) restore with the Latin1_General_CI_AS collation and almost certainly be fine. There is a list of compatible collations which Google should be able to help you find.
I had a notion to use a database column of type replication ID, but have since changed my approach and want to use this column for another purpose.
However, I'm unable to use SQL to drop the column to remove it from my database.
My SQL is:
ALTER TABLE foo_bar DROP COLUMN theFoo;
However, I get a "syntax error" and I'm assuming this has something to do with this column being a replication ID.
I'd rather not download the file and edit it directly using the MS Access application, but not sure if that's my only recourse.
Thanks so much in advance.
Regards,
Kris
If you have access to the database in a command shell, Michael Kaplan's Replication System Removal Fields utility should do the trick. However, I've found that in some circumstances, it's unable to do the job. Also note that the utility will only work with a Jet 4 format database (MDB), not ACE format (ACCDB).
If all else fails, you can recreate the table structure and append the existing data to it. That can get messy if you have referential integrity defined, though, but it will get the job done, and likely most of it is scriptable (if not all possible using just DDL).
Here is a link that may help you, I had a similar idea but when browsing the web found this
AccessMonster - Replication-ID-Field-size
EDIT: Well I don't have much time but what I was thinking of first was if you could alter the column to make it different (not a replication ID) and then drop it. (two separate actions). But I have not tested this.