I have a ASP.Net web application with connection string for SQL Server 2005 in the web.config.
Data Source=ABCSERVER;Network Library=DBMSSOCN;Initial Catalog=myDataBase;
User ID=myUsername;Password=myPassword;
I want to specify the collation property in the web.config for different languages like French like
Data Source=ABCSERVER;Network Library=DBMSSOCN;Initial Catalog=myDataBase;
User ID=myUsername;Password=myPassword;Collation=French_CS_AS
But the Collation word is not valid in the connection string.
What is the correct keyword that we need to use to specify the collation in SQL Server 2005 connection string?
Edit
I understand that collation can be set during the database installation and can also be changed. I do not want to change it permanently in the database. But I want the SQLClient to set the collation based on the application's settings.
I only want use it when using SQL Query like
SELECT * FROM TESTTABLE ORDER BY TESTCOLUMN COLLATE French_CS_AS
I am trying to ensure that for a given connection, all the commands/queries for that connection would automatically use the "French_CS_AS" - based on the property setting in the connection string, rather than changing the query definitions
You cannot set collation for a connection. It's simply not supported. See SQL Server Native Client: Connection strings and OLE DB for a really interesting blog article on how connection strings parse out.
You can set a language for a connection. Setting the language for a connection changes how dates are handled and causes system error messages to be provided in the specified language. See Session Language for more information on setting language.
A warning about using collations on non-Unicode types from COLLATE (Transact-SQL):
Code page translations are supported for char and varchar data types, but not for text data type. Data loss during code page translations is not reported.
Ideally, if you want consistent multilingual support from your data you should be using Unicode data types (nvarchar, etc.). You should also see the Collation and International Terminology article on MSDN for more information on this. It contains references to some additional articles that are quite useful as well so don't stop there.
Related
DB side: SQL Server 2012. A data column is char(1) datatype.
ORM: Hibernate
Intention: Hibernate Query can bind a parameter properly, so no implicit datatype conversion in the query.
//not working as I intend. DB side still sees nvarchar(4000)
Query.setCharacter("paramName", myChar)
Query.setParameter("paramName", myChar, Hibernate.Type.CHARACTER)
Query.setString("paramName", myCharStr)
None of above variation works. SQL server profiler indicates that the bound parameter type is navarchar(4000). SQL server ends up doing some implicit datatype conversion when running the query, and it messed up some of my initial intention. (Rare and elusive deadlocks (select for update; then update) in case of multiple concurrent transactions)
Also it came to my attention that JDBC PreparedStatement API does not even have "setCharacter()". Not sure if this means anything. (http://docs.oracle.com/javase/7/docs/api/java/sql/PreparedStatement.html )
Is there a way to achieve the intention to bind a fixed length char, not nvarchar?
Actually it is not a Hibernate issue. Rather it is that collation set on this particular db column is different than DB collation. Once collation on this data column is fixed, then any of above Hibernate method variation can bind proper parameter type. In case anyone else runs into similar issue.
Edit: another important setting is "sendStringParametersAsUnicode". SQL server JDBC driver by default sent character as "nvarchar" or "nchar", unless you append "sendStringParametersAsUnicode=false" in your connection string;
http://technet.microsoft.com/en-us/library/ms378988.aspx
http://blogs.msdn.com/b/sqlcat/archive/2010/04/05/character-data-type-conversion-when-using-sql-server-jdbc-drivers.aspx
I'd like to have a few details about how oracle (via sql/plus) determine the charset used to evaluate a sql script.
My database is configured like this:
select VALUE from nls_database_parameters where parameter='NLS_CHARACTERSET';
VALUE
------
WE8ISO8859P15
The problem is that I read here http://www.orafaq.com/wiki/NLS that session parameters could take precedence over database parameters.
Does it mean that database encoding is overriden by the one defined in the NLS_LANG environment variable of the user who executes the script?
Apparently, it's not possible to modify the encoding in a script via an alter session statement.
I'm asking this question since I already had a problem of corrupted characters with a production script executed by a subcontractor in India. I actually don't know if it was because he did something wrong with my file (like copy/paste in a sql gui client) or if it was because of his environment.
To summarize my actual problem, will everything be OK if
The user is configured with a charset of UTF8
My sql file is encoded in UTF8
My database is in WE8ISO8859P15
Thank's in advance for your answers.
Yes, you are correct. The Oracle Client always converts between the database characterset and the characterset of the client machine, which is determined by the NLS_LANG environment variable or the system settings.
Please note that UTF8 supports only Unicode version 3.1 and earlier. Use AL32UTF8 instead to get full Unicode support.
I will like to know what entity is responsible for doing the encoding conversions necessaries to accomplish a SQL command successfully. For example: you have several places where output a SQL command.
SELECT title from T1 where title='tÃtulo'
This may be execute from within the database client (which I assume it reads the database encoding and encode its commands after that) but what happen when this is a string in a programming language whose string encoding is not the same as the database?
Where the conversion takes place? In the class that connects to the database? The database and the connector do some kind of agreement when they are handshaking?
I'll love some information about this topic or some link where I can read about it.
Thanks in advance.
Case Java + MySQL
Internally in Java String is text is Unicode encoded.
In a Java source text should have the same encoding that the java compiler uses. A wrong matching between editor and compiler would mess up string literals.
Java thus transfers a Unicode string to the JDBC driver, the database client library.
The MySQL connections string can indicate which encoding to use in the client library to communicate with the database server. useEncoding=UTF-8, so Unicode, would be a good international choice.
The database can set a default encoding.
As also any table.
As also per column (say one for Hindi one for Chinese).
Besides the encoding, also the collation (sorting order of strings) is language and encoding specific. And have to be considered too.
I'm attempting to run a simple statement against an Access DB to find records.
Data validation in the records was horrible, and I cannot sanitize it. Meaning, it must be preserved as is.
I need to be able to search against a string with white space and hyphen characters removed. The following statement will work in Access 2010 direct:
select * from dummy where Replace(Replace([data1],' ',''),'-','') = 'ABCD1234';
Running it from an ODBC connection via PHP will not. It produces the following error:
SQL error: [Microsoft][ODBC Microsoft Access Driver] Undefined function 'Replace' in expression., SQL state 37000 in SQLExecDirect
Creating a query in the database that runs the function and attempting to search its values indirectly causes the same error:
select * from dummy_indirect where Expr1 = 'ABCD1234';
I've attempted to use both ODBC drivers present. ODBCJR32.dll (03/22/2010) and ACEODBC.dll (02/18/2007). To my knowledge these should be current as it was installed with the full Access 2010 and Access 2010 Database Engine.
Any ideas on how to work around this error and achieve the same effect are welcome. Please note, that I cannot alter the database in way, shape, or form. That indirect query was created in another mdb file that has the original tables linked from the original DB.
* Update *
OleDB did not really affect anything.
$dsn= "Provider=Microsoft.ACE.OLEDB.12.0;Data Source=c:\dummy.mdb;";
I'm not attempting to use it as a web backend either. I'm not a sadomasochist.
There is a legacy system that I must support that does use Access as a backend. Data gets populated there from other old systems that I must integrate into more modern systems. Hence, the creation of an API with Apache/PHP that is running on the server supporting the legacy system.
I need to be able to search a table that has an alphanumeric case identifier to get a numeric identifier that is unique and tied to a generator (Autonumber in access). Users have been using it a trash box for years (inconsistent data entry with sporadic notations) so the only solution I have is to strip everything except alphanumeric out of both the field value and the search value and attempt to perform a LIKE comparison against it.
If not replace() which is access supported, what ODBC compatible functions exist that I can use do the same kind of comparison?
Just to recap, the Access db engine will not recognize the Replace() function unless your query is run from within an Access application session. Any attempt from outside Access will trigger that "Undefined function" error message. You can't avoid the error by switching from ODBC to OleDb as the connection method. And you also can't trick the engine into using Replace() by hiding it in separate query (in the same or another Access db) and using that query as the data source for your main query.
This behavior is determined by Access' sandbox mode. That linked page includes a list of functions which are available in the default sandbox mode. That page also describes how you can alter the sandbox mode. If you absolutely must have Replace() available for your query, perhaps the lowest setting (0) would allow it. However, I'm not recommending you do that. I've never done it myself, so don't know anything about the consequences.
As for alternatives for Replace(), it would help to know about the variability in the values you're searching. If the space or dash characters appear in only one or a few consistent positions, you could do a pattern match with a Like expression. For example, if the search field values consist of 4 letters, an optional space or dash, followed by 4 digits, a WHERE clause like this should work for the variations of "ABCD1234":
SELECT * FROM dummy
WHERE
data1 = 'ABCD1234'
OR data1 Like 'ABCD[- ]1234';
Another possibility is to compare against a list of values:
SELECT * FROM dummy
WHERE
data1 IN ('ABCD1234','ABCD 1234','ABCD-1234');
However if your search field values can include any number of spaces or dashes at any position within the string, that approach is no good. And I would look real hard for some way to make the query task easier:
You can't clean the stored values because you're prohibited from altering the original Access db in any way. Perhaps you could create a new Access db, import the data, and clean that instead.
Set up the original Access db as a linked server in SQL Server and build your query to take advantage of SQL Server features.
Surrender. :-( Pull in a larger data set to your PHP client code, and evaluate which rows to use vs. which to ignore.
I'm not sure you can do this with ODBC and your constraints. The MS Access driver is limited (by design; MS wants you to use SQL Server for back ends).
Can you use OLEDB? that might be an option.
Three questions with the following scenario:
SQL Server 2005 production db with a Latin1 codepage and showing "?" for invalid chars in Management Studio.
SomeCompanyApp client as a service that populates the data from servers and workstations.
SomeCompanyApp management console that shows "?" for Asian characters.
Since this is a prod db I will not write to it.
I don't know if the client app that is storing the data in the database is actually storing it correctly as Unicode and it simply doesn't show because they are using Latin1 for the console.
Q1: As I understand it, SQL Server stores nvarchar text as Unicode regardless of the codepage or am I completely wrong and if the codepage is Latin1 then everything that is not in that codepage gets converted to "?".
Q2: Is it the same with a text column?
Q3: Is there a way using SQL Server Management Studio or Visual Studio and some code (don't care which language :)) to query the db and show me if the chars really do show up as Japanese, Chinese, Korean, etc.?
My final goal is to extract data from the db and store it in another db using UTF-8 to show Japanese and other Asian chars as what they are in my own client webapp. I will settle for an answer to Q3. I can code in several languages and at the very least understand some others but I'm just not knowledgeable enough about Unicode. In case you want to know my webapp will be using pyodbc and cassandra but for these questions that doesn't matter.
When inserting into an NVARCHAR column in SSMS, you need to make absolutely sure you're prefixing your string with a N:
This will NOT work:
INSERT INTO dbo.MyTable(NVarcharColumn) VALUES('Some Text with Special Char')
SQL Server will interpret your string in the VALUES(..) as VARCHAR and thus strip off any special characters.
You need this:
INSERT INTO dbo.MyTable(NVarcharColumn) VALUES(N'Some Text with Special Char')
Prefixing your text literal with an N'..' tells SQL Server to treat this as NVARCHAR all the way.
Does this help you solve your Q3 ??