Database Collation VS Column Collation

I have some Collation problem I need a help, please!
I have two SAME test databases,
but one (A) has a Collation set to Hebrew_CI_AS, and another one (B) - SQL_Latin1_General_CPT1_CS_AS.
Both databases have a Synopsis table with a column NVARCHAR(1000), holding programmes EPG.
In database (A) the COLUMN's Collation is set to SQL_Latin1_.... ( an opposit to the database ! )
In database (B) the COLUMN's Collation is set to Hebrew_CI_... (again - an opposit to the database)
My problem is:
When I want to update this column on databse (A) with special latin tags, f.e. ñç, I get question marks only: UPDATE A..Synopsis SET ... = 'Pour Bébé' shows me Pour B?b?
On the other hand, if in database (B) I want to type some Hebrew carachters, I get ???????? as well.
It seems that despite I have a specified collation on my column, SQL keeps ignore it.
How can I fix it?
Many thanks in advance

My problem is:
When I want to update this column on databse (A) with special latin tags, f.e. ñç, I get question marks only: UPDATE A..Synopsis SET ... = 'Pour Bébé' shows me Pour B?b?
On the other hand, if in database (B) I want to type some Hebrew carachters, I get ???????? as well.
I see Ed bumped this old unanswered thread. Even though you've probably since resolved the issue, I'll answer it to help others that may run into the same issue.
Collation affects non-Unicode string literals and the characters that can be stored for non-Unicode columns (char and varchar). Unicode columns (nchar and nvarchar) can store all the characters you mentioned properly. The character conversion
problem occurs here because you are you are not indicated a Unicode character string literal so the value is interpreted as an non-Unicode string literal and converted according to the database default collation.
To fix the problem, prefix the literal string with an N to indicate a Unicode string line the example below. If the SQL is executed from a client application, the best solution is to use properly typed parameters instead of string literals.
SET ... = N'Pour Bébé'
Dan Guzman, SQL Server MVP, http://www.dbdelta.com

Similar Messages

Project Server (SharePoint) - Database Collation question.

Hi,
I have been looking at the performance of our SharePoint database server and one of its uses is Project Server.
Our databases are set as follows
Project Server Databases (Latin1_General_CI_AS)
SharePoint Server Content Databases (Latin1_General_CI_AS_KS_WS)
TempDB (Latin1_General_CI_AS)
It seems that the Project Server databases should be (SQL_Latin1General_CP1_CI_AS):
https://technet.microsoft.com/en-us/library/ff800813(v=office.14).aspx
e.g.
Database
Collation
Project Server Archive
SQL_Latin1_General_CP1_CI_AS
Project Server Draft
SQL_Latin1_General_CP1_CI_AS
Project Server Published
SQL_Latin1_General_CP1_CI_AS
Project Server Reporting
SQL_Latin1_General_CP1_CI_AS
SharePoint Server Content
Latin1_General_CI_AS_KS_WS
I may be worrying unnecessarily but my understanding was that the tempdb should be the same collation as the user databases (where possible). With the SharePoint content and the Project Server databases on the same instance this is not possible.
Should I...
1. Not worry about it (the performance impact is negligable).
2. Create seperate instances so that the TempDB can match the user databases (I am worried that the overhead of an extra instance will be more than the overhead of different collations).
3. Implement Contained/Partially contained databases (new possible option)
4. Something else?
Also how bad is it that the Project server databases are Latin1_General_CI_AS rather than SQL_Latin1General_CP1_CI_AS.
Thanks in advance
Shaun

Hi Prasanna,
thank you for taking the time to respond.
From the link - I read this as Microsoft insisting that you use Latin1_General_CI_AS_KS_WS for the SharePoint content databases and recommending it for the system databases including TempDB?
Our TempDB is not the same collation as the SharePoint content databases but the same as the Project Server databases. Which brings me back to my original questions.
From the Technet article:
The following TechNet Article talks about the SQL Server collation for the SharePoint databases
http://technet.microsoft.com/en-us/library/cc288970.aspx#section1
“The SQL Server collation must be configured for case-insensitive. The SQL Server database collation must be configured for case-insensitive, accent-sensitive, Kana-sensitive, and width-sensitive. This is to
ensure file name uniqueness consistent with the Windows operating system.”
However, we do not support changing the default collation (Latin1_General_CI_AS_KS_WS) for SharePoint databases to any other collations (CI, AS, KS, WS).
We support any CI collation for the SQL instance (for master, tempdb databases). However we
recommend using Latin1_General_CI_AS_KS_WS as the instance default collation (master, tempdb databases).

Database Collation Conversion

Hi Guru's,
I am trying to copy Production to a new Test server. Production is 32-bit SQL 2000 the new Test Server is x64 bit and SQL 2005.
The problem I face is with the database Collation. Production database is SQL_Latin1_General_CP850_BIN and I'm trying to get it to SQL_Latin1_General_CP850_BIN2 before attaching it to SQL 2005 on the new Test server. I used INSTCOLL.EXE as advised in OSS 600027 and recieved the following message :
Trying to connect...
Connected to <<SERVERNAME>>
Executing conversion of database <<SID>>
Database <<SID>> has been converted to collation SQL_Latin1_General_CP850_BIN2.
However, select databasepropertyex('<<SID>>', 'collation') still returns SQL_Latin1_General_CP850_BIN
The 'server collation' is SQL_Latin1_General_CP850_BIN. Would this affect how the INSTCOLL.EXE would work?
I tried attaching the database to SQL 2005 as SQL_Latin1_General_CP850_BIN and converting it from there and got this message :
Trying to connect...
Connected to <<SERVERNAME>>
This program will only run against SQL Server 2000 newer or equal to version 8.00.780.
Your server is 9.0.3175
You must install SQL 2000, SP3 and the Unicode Hotfix (QFE).
NOTHING DONE!
Can someone please suggest another way to get the SQL 2000 database to BIN2? Or perhaps offer a suggestion to where I'm going wrong with the conversion?
Thanks,
Kye

Hi,
The permitted collations for SQL Server 2000 are as follows:
o SQL_Latin1_General_CP850_BIN (BIN) and
o SQL_Latin1_General_CP850_BIN2 (BIN2).
Only the following 3 combinations are supported by SAP:
.SAP-Basis................
.SQL.Server....
.<SAP.DATABASE>.
.non-Unicode.and.non-Java.
.BIN...........
.BIN............
.non-Unicode.and.non-Java.
.BIN2..........
.BIN2...........
.Unicode.or.Java..........
.BIN2..........
.BIN2...........
The same collation must always be installed for the SQL Server and the
database.
For a non-Unicode system that does not contain any Java components, you can
select both BIN and BIN2. With a Unicode system or a system that contains
Java components, you must select BIN2 as the collation for the server and
database.
For more details refer SAP Note : 505906.
Regards,
Nikunj

How to store España in database (in a column of a table)

Could you please tell me how to store España in database (in a column of a table).
regards

Generally speaking you'll need a character set that can support the characters you require.
Here is a link to the supported character sets in 10.2.x.x:
[Character Sets|http://download.oracle.com/docs/cd/B19306_01/server.102/b14225/applocaledata.htm#i635016]

AlwaysOn & Contained Databases Collation Conflict

Here is my situation.
I have setup an alwaysOn availability group which is working fine.
In this AlwaysOn availability group I have converted the Adventureworks database to a contained database. I also added a Contained User.
Connecting to the secondary "Contained" database was no problem.
But here is my problem, when expanding the tables I received the following errormessage:"Cannot resolve collation conflict between "Latin1_General_CI_AS" and "Latin1_General_100_CI_AS_KS_WS_SC" in add operator occurring in SELECT statement
column 3."
Doing this action on the primary is no problem. Executing a select statement against the secondary is also no problem and returns a result.
After some trial and error, I’ve seem to fixed the issue by doing a failover to all my secondary databases.
After, expanding the tables to the primary & secondary worked.
Does anybody have an idea why this happened, and am I the only one experiencing this issue?
Thanks, Bram

Hi
Please refer to the link below:
http://blogs.msdn.com/b/sql_pfe_blog/archive/2013/02/26/sql-server-2012-partially-contained-databases-part-2-collation.aspx

Database adapter and column aliases in the select statement (10.1.3.1)

Hi,
Is it possible to use column aliases in the select statement for a database adapter to return an xml element name which is different to the column in the queried table?
I have tried using
SELECT EMPLOYEE_ID, FIRST_NAME AS MYNAME, LAST_NAME, SALARY, DEPARTMENT_ID, PHONE_NUMBER, EMAIL, HIRE_DATE FROM HR.EMPLOYEES WHERE (DEPARTMENT_ID = #DEPT_ID)
but I get the following XML fragment returned
<Employees>
<employeeId>100</employeeId>
<firstName xsi:nil="true" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"/>
<lastName>King</lastName>
<salary>24000</salary>
Any pointers appreciated.
Joel.

That is really interesting.
When I use the "custom sql" option in the DB adapter wizard, it used the aliases just fine in the return schema.
Marc

Type of object from a database date/time column

Hello everyone,
I've got a concern regarding the way in which coldfusion is
treating date/time columns in a database.
In my opinion when I select a column that is let's say
timestamp type - the object in a query is CF's date/time object.
I've checked the query by getMetaData() and it looks like each
column has its own database type (eq. varchar2, date, etc).
My concern comes from a fact that I've heard that Coldfusion
is treating the date-time columns in a database as strings and in
each case it parses them. So the difference in a locale between a
database server and a Coldfusion server may result in a wrong
date/time object.
Example:
Locale of database EU: yyyy/mm/dd
Locale of Coldfusion US: yyyy/dd/mm
The date like 1st of February 2007 stored in a database would
look then in Coldfusion like: 2nd of January 2007
Could someone please confirm which version is valid?

Johnny852 wrote:
> In my opinion when I select a column that is let's say
timestamp type - the
> object in a query is CF's date/time object. I've checked
the query by
> getMetaData() and it looks like each column has its own
database type (eq.
> varchar2, date, etc).
if you already know cf is returning a datetime from a
datetime in the db, what's
the question?
> My concern comes from a fact that I've heard that
Coldfusion is treating the
"fact"? unless the datetime is stored as a string, that's not
a "fact".
> Example:
> Locale of database EU: yyyy/mm/dd
> Locale of Coldfusion US: yyyy/dd/mm
btw neither of your example "locales" are in fact locales.
> The date like 1st of February 2007 stored in a database
would look then in
> Coldfusion like: 2nd of January 2007
if you pass a numeric string representation (2/1/2007 for
instance) of a date to
cf, it will be interpreted via the cf server's "default"
local (ie en_US,
month/day/year) unless you use one of the LS functions like
LSParseDateTime() &
specifically set the the locale (like setLocale("th_TH")) or
make the date
non-ambiguous (2-feb-2007) or build the date yourself from
user input using
createDate() or createDateTime(). you just need to convert
the user's string
representation to a valid cf datetime object (or i guess
force to database to
follow the user's locale date mask).

Direct Database Request - Incorrect Column Data type

Hello All -
hope you can help with this. I'm using the Direct Database Request in Oracle BI to send a complex query directly to our data warehouse. My problem is that the result columns containing my measures are converted to integer by Oracle BI when they should be double. The integer conversion causes decimal values to be rounded, reading to incorrect results in my reports. I've tried several tweeks to my query in an attempt to allow OBIEE to make the correct guess on the data type but nothing has worked.
Is there a way to force OBIEE to recognize the correct data type for a column in a Direct Database Request Query?
Thanks in advance for you help!
Mac

Thank you both.
David's response was helpful from a style/readability perspective (the columns in question were complex expressions) but I had already attempted the approach and it hadn't solved the formatting issue. Nico's response solved the problem.
Regards,
Mac

SQL Developer 1.5.1 - Database Export - Exporting Column Comments

I have tried using the Database Export tool in SQL Developer 1.5.1 to export statements for "comment on column" but with no success. Is there a way to get these statements included in the DDL?
rasberry

When you select 'table' the comments are generated 'automatically'.
This is what you want?

Toplink JPA forces database table and column names to UPPERCASE! Why?

I have recently experienced using Toplink JPA while using glassfish ... migrating an existing application to EJB 3.0 persistence. Toplink JPA, as implemented in glassfish, forces tablenames and column names from my code to be uppercase in select statements, etc. as then submitted to the database. Why? I cannot find anything in the EJB 3.0 specs on persistence that even suggests this.
This created a serious problem for me, in my application. For my code to work I had to change the names of the database tables to all uppercase, even though that meant other of my applications, already written using the original mixed case names of the databases, will no longer work unless I revise the code in those applications! (I am using mySQL as my database.)
In both Unix/Linux and Java, which are both case sensitive, If I wanted names of files or other items to be uppercase, I would have written them that way. I do not expect some middleware piece of software to muck around with the case of text I have put into my code.
I am hopeful this 'feature' of the reference implementation of the EJB Persistence API will be corrected in a subsequent version. [Maybe you can tell I am not happy!]
Thanks for listening to my rant.

Robert,
I found that the name I specify in all of my @Table, @Column, ... annotations is used with the case as it is provided.
If TopLink determines the schema information through defaults then the names it comes up with are definitely upper cased by default.
Are you specifying the schema information that you want in annotations or XML?
Doug

Database Diff - One column and triggers won't fall off report

I'm trying to use the database diff tool (which I LOVE, by the way), and I'm getting just a few odd results. I'm comparing two databases and can never seem to get to where the diff report is empty, even though everything is the same. No matter what I do, it lists one column in a table as different and lists ALL 13 triggers in the database as different. I have tried dropping the table and all triggers in question and having the diff scripts recreate them, but when I try a diff again, they keep showing up as different somehow.
Also, the diff script is generating this as code to modify the column:
alter table "USERS" modify ( "UPID" NVARCHAR2 );
Which I don't think is valid syntax - I get "Missing left parentheses." I think it's because it doesn't like specifying the NVARCHAR2 type without a size. If I change that statement to NVARCHAR2(20), then the statement runs. However, as I said before, it still shows up in the diff report later on as if something is different, even though both databases are exactly the same.
I'm using SQL Developer 2.1.1.64 on Windows XP Pro. Database is 10g.

Does the ext directory have the php_oci8.dll? In the original steps the PHP dir is renamed. In the given php.in the extension_dir looks like it has been updated correctly. Since PHP distributes php_oci8.dll by default I reckon there would be a very good chance that the problem was somewhere else. Since this is an old thread I don't think we'll get much value from speculation.
-- cj

X^2 + y^2 =z^2 in database as a column

how to save formulae in a database eg x^2 + y^2 =z^2 as a column.This should look like x square + y square = z square.

Something like this?
SQL> create table formula (x number, y number, f varchar2(200));
Table created.
SQL> insert into formula values (3,5,'sqrt(power(x,2)+power(y,2))');
1 row created.
SQL> insert into formula values (2,3,'power(x,2)+power(y,2)');
1 row created.
SQL> ed
Wrote file afiedt.buf
1 select
2    x,y,f,
3    to_number(
4      extractvalue(
5        xmltype(dbms_xmlgen.getxml('select '||replace(replace(f,'x',x),'y',y)||' c from dual'))
6        ,'/ROWSET/ROW/C')) z
7* from formula
SQL> /
         X          Y F                                                 Z
         3          5 sqrt(power(x,2)+power(y,2))              5.83095189
         2          3 power(x,2)+power(y,2)                            13

11g TP3 / ADF BC / Support for database type in column

Is it necessary to instantiate an object of corresponding type in the row implementation class to manage the corresponding type attributes like in 10g ?
Example from 10g :
protected void create(AttributeList attributeList)
super.create(attributeList);
ApplicationModule root = getDBTransaction().getRootApplicationModule();
DBSequence seqid = new DBSequence("customers_seq",root);
setCustomerId(seqid.getSequenceNumber());
try
CustAddressTyp custAddr = new CustAddressTyp();
this.setCustAddress(custAddr);
catch (Exception e)
e.printStackTrace();
}

We currently don't offer support for Oracle ADF BC in Eclipse and while we might consider this for a future release this is not planned right now.

How to change collation at Database level

Hi ,
I need to change one of my database collation . Actually the server collation and database collation is differently . I dont want to change server level collation. I want to change only database collation . Please let me know the various methods are
available for this activity. Please suggest me how to proceed ..........
Thanks in advance ....... :)
Regards
Pradeep

Hi Eeland,
Yes .... you are absolutely correct . Actually this is production server also . Before going to implement i need to prepare a document , what are the steps i will follow. If you have free time ...... please help me.
Regards
Pradeep
You can use script as below
DECLARE @Query varchar(max)
SELECT @Query = COALESCE(@Query + ';','') + 'ALTER TABLE ' + TABLE_NAME + ' ALTER COLUMN ' + COLUMN_NAME + ' ' + DATA_TYPE + '(' + CASE WHEN CHARACTER_MAXIMUM_LENGTH = -1 THEN 'max' ELSE (CAST(CHARACTER_MAXIMUM_LENGTH AS varchar(5)) END + ') ' + CASE WHEN IS_NULLABLE = 'YES' THEN ' NULL ' ELSE ' NOT NULL ' END + ' COLLATE <new collationname here>'
WHERE DATA_TYPE IN ('text','ntext','varchar','char','nvarchar','nchar')
PRINT (@QUERY)
--EXEC (@QUERY)
But I second Erlands suggestion. First see the generated code and checkk it carefully before applying to prod environment
Please Mark This As Answer if it helps to solve the issue Visakh ---------------------------- http://visakhm.blogspot.com/ https://www.facebook.com/VmBlogs

11g HS ODBC database link only returning one column

Hi,
We having a problem with a HS ODBC database link to a SQLServer database - only one column is being returned (when we do a simple 'select * from remote_table@SQLServer_dblink'). We recently set up another HS database link to a MySQL database and that's works okay, even though the init*.ora files have the same settings configured.
Any ideas what might cause this?
This is the trace file:
Oracle Corporation --- FRIDAY OCT 28 2011 14:26:33.827
Heterogeneous Agent Release
11.2.0.2.0
Oracle Corporation --- FRIDAY OCT 28 2011 14:26:33.827
Version 11.2.0.2.0
HOSGIP for "HS_FDS_TRACE_LEVEL" returned "ON"
HOSGIP for "HS_FDS_SHAREABLE_NAME" returned "/usr/lib/libodbc.so"
HOSGIP for "HS_OPEN_CURSORS" returned "50"
HOSGIP for "HS_FDS_FETCH_ROWS" returned "100"
HOSGIP for "HS_LONG_PIECE_TRANSFER_SIZE" returned "65536"
HOSGIP for "HS_NLS_NUMERIC_CHARACTER" returned ".,"
HOSGIP for "HS_KEEP_REMOTE_COLUMN_SIZE" returned "OFF"
HOSGIP for "HS_FDS_DELAYED_OPEN" returned "TRUE"
HOSGIP for "HS_FDS_WORKAROUNDS" returned "0"
HOSGIP for "HS_FDS_MBCS_TO_GRAPHIC" returned "FALSE"
HOSGIP for "HS_FDS_GRAPHIC_TO_MBCS" returned "FALSE"
HOSGIP for "HS_FDS_RECOVERY_ACCOUNT" returned "RECOVER"
HOSGIP for "HS_FDS_TRANSACTION_LOG" returned "HS_TRANSACTION_LOG"
HOSGIP for "HS_FDS_TIMESTAMP_MAPPING" returned "DATE"
HOSGIP for "HS_FDS_DATE_MAPPING" returned "DATE"
HOSGIP for "HS_FDS_MAP_NCHAR" returned "TRUE"
HOSGIP for "HS_FDS_RESULTSET_SUPPORT" returned "FALSE"
HOSGIP for "HS_FDS_RSET_RETURN_ROWCOUNT" returned "FALSE"
HOSGIP for "HS_FDS_PROC_IS_FUNC" returned "FALSE"
HOSGIP for "HS_FDS_REPORT_REAL_AS_DOUBLE" returned "FALSE"
using MySQL_CSSUser as default value for "HS_FDS_DEFAULT_OWNER"
HOSGIP for "HS_SQL_HANDLE_STMT_REUSE" returned "FALSE"
hgocont, line 2754: calling SqlDriverConnect got sqlstate I

The characterset on our Oracle DB is AL16UTF16, but we have already tried several language settings without success (see commented out sections in the *.ora file below) - but interestingly not a UTF16. Is that the problem, do you think?
The collation on the SQLServer DB is 'SQL_Latin1_General_CP1_CI_AS', if that makes any difference. The db server is Linux (5.6), Oracle db is 11.0.2.0 and the SQLServer db is v.8.
We don't get an error when using the dblink...it's just that only the last column is returned. If we explicitly select any other columns, we get the 'invalid identifier' error. It's the same with whatever table we dblink to...the columns are just standard chars and numerics, nothing large or custom, etc.
I'll try and dig up the full trace file....
HS_FDS_CONNECT_INFO=CSS_ST
set ODBCINI=/etc/odbc.ini
HS_FDS_TRACE_LEVEL = DEBUG
HS_FDS_SHAREABLE_NAME = /usr/lib/libodbc.so
HS_FDS_SQLLEN_INTERPRETATION=32
#HS_LANGUAGE=AMERICAN_AMERICA.WE8ISO8859P1
#HS_LANGUAGE=AMERICAN_AMERICA.WE8MSWIN1252
#HS_LANGUAGE=AMERICAN_AMERICA.UTF8
set ODBCINSTINI=/etc/odbcinst.ini
set LD_LIBRARY_PATH=/usr/local/easysoft/lib:/usr/local/easysoft/sqlserver/lib:/usr/lib:/u01/app/oracle/product/11.2.0/dbhome_1/lib
-------------------------------------------------------------------------------------------------------------------------------------------------------------------------

Database Collation VS Column Collation

Similar Messages

Maybe you are looking for