Is it possible to change the default collation based on a column? i want to make 1 column case sensitive but all the others not
ALTER TABLE ALTER COLUMN allows to change collation for a single column:
alter table Foo alter column Bar ntext collate Latin1_General_CS_AS
(collation might be incorrect)
I don't specifically know SQL Server, but the generally accepted DBMS practice (for compatibility) would be to either:
put insert and update triggers on the table so that they're stored in the case you want.
use generated columns to store another copy of the column in the case you want.
There may be a faster way to do it in SQL Server but you should be careful of solutions that push workload into the SELECT statements - they never scale well. It's almost always better doing this as part of inserts and updates since that's the only time data changes - doing it that way minimizes the extra workload.
The answer to your question is yes, already stated above by Anton Gogolev.
Additional Info:
Here is a how you can find list of Collation supported by your SQL Server based on its version.
select name,
COLLATIONPROPERTY(name, 'CodePage') as Code_Page,
description
from sys.fn_HelpCollations()
what is the meaning of Kanatype Sensitive KS and width sensitive
Related
Are there any configuration or option to make permanent change to the column collation so that I don't have to repeat COLLATE everywhere?
The following is my SQL query:
select
y.[Key] FieldName,
(select FieldName
from [dbo].GetFields(z.[Key])
where FieldType = y.[Key] COLLATE Chinese_Taiwan_Stroke_CI_AS) COLLATE Chinese_Taiwan_Stroke_CI_AS
from
FieldTableZ z
outer apply
FieldTableY y
It's unclear what are you trying to do here .. to change the collation of the entire server, the database or just for some columns? I'd try to answer all of them. A simple googling of "sql server change database collation" brings up these:
To change the server collation, there's the official documentation from Microsoft:
Set or Change the Server Collation
And if you want a step-by-step guide, here it is:
Changing SQL Server Collation After Installation - by Douglas Castilho
To change the database collation, for exmaple:
ALTER DATABASE CURRENT COLLATE SQL_Latin1_General_CP1_CI_AI
To change the collation of a table column:
Change SQL Server Database Collation - Paris Polyzos' blog
That is, you can alter the column collation with
ALTER TABLE [<Table>] ALTER COLUMN [<Column>] <ColumnType> COLLATE <NewCollation>
It's not the case if you are using graph tables; the graph internal columns cannot be altered that way.
I'd nevertheless guess that none of these are acceptable for what the query looks like -- you made your [Key] column (which looks like a primary key) duplicate in the query and trying to rely on the side effect of collation .. BTW, try not to let people just do the googling work for you.
I want a script that inserts table comments and column comments. Said script must be unique and run satisfactorily both on Oracle and MySQL. Furthermore, I prefer it to be written in Standard SQL.
This is how I do it now. But it does not work on MySQL.
comment on table F_Transaction
is 'Fact table for system transactions';
comment on column F_Transaction.Transaction_Date
is 'Date in which the transaction took place';
What SQL construction should I use to achieve my purpose?
The standards do not seem to define any way to define table or column comments (looks like they don't even mention them). So, the syntax for comments on tables/columns can vary from one DBMS to another.
It seems that a number of DBMS agree with Oracle's COMMENT ON syntax (see Oracle create table with column comments).
With MySQL it's necessary to specify the comments along with the table/column definition (in CREATE TABLE or ALTER TABLE sentences). See this related question: Alter MYSQL Table To Add Comments on Columns.
Originally, I created my SQL Server database on a local computer. I set its collation to Latin1_General_CI_AI and everything worked well. When I moved the finished work to the web hosting SQL Server, I encountered problem: they use a different database collation. So what can I do now?
To be more specific, I need Latin1_General_CI_AI, but they have Czech_CI_AS. These two differ significantly when comparing strings in Czech language (surprisingly I need latin1 general, not Czech, to get correct results.)
When I tried to change collation of my database, the server complained that I don't have user permission to do that. I tried to contact support desk, but no luck. Can I help myself?
I know that possibly each single table column can have its own collation, so maybe I should set up all my string columns to Latin1_CI_AI. But I don't know how to do this. I have only SQL access to the database (unfortunately no SQL Server Management Studio).
To change the database's collation
ALTER DATABASE MyDataBase COLLATE [NewCollation]
To change the collation of a column
ALTER TABLE MyTable ALTER COLUMN Column1 [TYPE] COLLATE [NewCollation]
But there are a number of limitations on when you can do this, very notably that this is denied if the column is used in any index.
You can do more in SSMS in some cases.
The syntax docs list the restrictions:
https://learn.microsoft.com/en-us/sql/t-sql/statements/alter-table-transact-sql?view=sql-server-2017
https://learn.microsoft.com/en-us/sql/t-sql/statements/collations?view=sql-server-2017
I tried this code and it's working for me :
ALTER TABLE dbo.MyTable
ALTER COLUMN CharCol VARCHAR(50) COLLATE Latin1_General_100_CI_AI_SC_UTF8
reference : https://learn.microsoft.com/en-us/sql/relational-databases/collations/set-or-change-the-column-collation?view=sql-server-ver15
I need to change column datatypes in a database table from varchar to nvarchar in order to support Chinese characters (currently, the varchar fields that have these characters are only showing question marks).
I know how to change the values, but I want to see if it's safe to do so. Is there anything to look out for before I do the changing? Thanks!
Note that this change is a size-of-data update, see SQL Server table columns under the hood. The change will add a new NVARCHAR column, it will update each row copying the dta from the old VARCHAR to the new NVARCHAR column, and then it will mark the old VARCHAR column as dropped. IF the table is large, this will generate a large log, so be prepared for it. After the update, run DBCC CLEANTABLE to reclaim the space used by the former VARCHAR column. If you can afford it , better run ALTER TABLE ... REBUILD, which will not only reclaim the space it will also completely remove physical deleted VARCHAR column. The linked article at the beginning has more details.
You may also be interested in enabling Unicode Compression for your table.
You can do on non primary key fields:
ALTER TABLE [TableName]
ALTER COLUMN [ColumnName] nvarchar(N) null
On the primary key fields it will not work - you will have to recreate the table
Make sure that the length doesn't exceed 4000 since the maximum for VARCHAR is 8000 while NVARCHAR is only 4K.
The table will get bigger. Each character in the column will take twice the space to store. You might not notice unless the table is really big.
Stored procedures/views/queries that work with the column data might need to be modified to deal with the nvarchar.
Check all the dependencies for this table as stored procs, functions, temp tables based on this table and variables used for inserts/updates etc may also need to be updated to NVARCHAR.
Also check if the table is in replication! That could cause you a new set of problems!
I am trying to dynamically create a SQL table only if it's not already existing. I have seen many solutions on the internet but they usually rely on a specific database, while I'm trying to find the most generic solution.
I was thinking of always running the CREATE command and then assuming that if it fails then the table exist and I can start inserting data into it. I can't see any flaw in this reasoning (not counting performance issues), but I might be wrong.
Is this an acceptable method?
Can you suggest other methods which are database independent, or that use ANSI SQL that all RDBMS would accept?
if there is a table - say - EMP, does that really imply that it is the same EMP that you are expecting?
Either query the appropriate data dictionary for the table structure, or fill your code with a ton of error checking and conditional logic...
INFORMATION_SCHEMA is part of the ANSI SQL Standard, so you should be able to:
IF NOT EXISTS(SELECT NULL FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'YourTable')
CREATE TABLE...
what about: create table if not exists