I have an old SQL Server 2000 database from which I read data. My problem is every query involving a String returns a value the size of that column filled with blank spaces.
e.g: let's say we have a column called NAME CHAR(20). All queries would return:
"John "
instead of just "John".
Is there a configuration or parameter in my database that causes this, or anything at all that can be changed to avoid it? Thank you.
EDIT:
I'd like to clarify, I'm reading my DB using JPA Repositories. I don't want to physically remove the whitespaces from the columns, or trim the values manually using RTRIM/LTRIM/REPLACE. I'm just trying to retrieve the column without trailing spaces, without adding any extra strain to the query or trimming the fields programatically.
you can use REPLACE/RTRIM/LTRIM
select RTRIM(LTRIM(column_name)) from table_name
or
select replace(column_name, ' ', '') from table_name
Related
I have a column which was set to Varchar and the database set to SQL_Latin1_General_CP1_CI_AS.
When a user entered their name into our web front end and save the data, it was not saving accented characters correctly.
The web user was entering the following, "Béala" but this was being saved on the database as the following, "Béala".
I believe that changing the column from Varchar to NVarchar should prevent this from happening going forward(?), however, I have two questions.
1) How do I perform a select on the existing data in the column and display it correctly?
select CONVERT(NVARCHAR(100),strAddress1) from [dbo].[tblCustomer]
This still shows the data incorrectly.
2) How do I update the data in the column once converted to NVarchar to save the accented characters correctly?
Many thanks,
Ray.
The only idea that came to my mind is that you have to prepare an update that will fool this badly loaded data, i.e. a sign
'é' will always match exactly one character (in this case 'é'), you have to catch all special characters and this
as have been changed (just a simple update with cases and replace). Of course, the first column must be of the nvarchar type.
It solves the problem 1 and 2 (the data will be correct in the table, the data will be displayed correctly, I described the update above)
Here is way to get it in normal characters scheme.
select 'Réunion', cast('Réunion' as varchar(100)) COLLATE SQL_Latin1_General_CP1253_CI_AI
Moreover to check all possible collations in SQL Server you can try this query
SELECT name, description
FROM sys.fn_helpcollations();
I have two databases and I am moving data from one database another. On some columns I need to resolve a collation conflict between "Latin1_General_CI_AS" and "Latin1_General_CI_AI". So I currently do:
SELECT [column] COLLATE Latin1_General_CI_AI
FROM xxx
This works in the main but in some fields I see characters like:
�
In the data that has been copied across. It seems some characters from the original DB are lost when the collation is changed on the new DB. Now I know I can use REPLACE to get rid of them, but I wondered rather than search the entire record set - is there a way to filter out or prevent the special characters coming across in the first place?
I want to store values which contains special character like ', " etc in database table filed which have datatype varchar. Like I want to store 'Sale'sStore' value in table.
How can I store it. Currently I was not able to store it.
it depends on where from are you trying to insert these strings. If manualy, so just insert \ before ' and it should be fine. If you are creating your query programatically, you should consider using binding function to build the query(they will solve it automatically) and not build them just with concatenating strings
Not sure if this is an appropriate "programming" issue but its relevant.
Is there a way via SQL or excel even to add quotes to a big number of values, for example i want to add values a,b,c,d,e,f,g,j etc etc to a table is there a way i can automatically add quotes to them? as in 'a','b' etc...
i have this issue especially in my select * from table where column in ('value1','value2')...
Thanks...
I usually tackle this sort of issue using Excel - if you enter your source values in a column, you can then just use an Excel formula to concatenate the values with quotes around them (eg =CONCATENATE("'", A1, "'")), and even extend this to build the complete SQL statement.
Not sure if this helps or is what you were asking, but for such queries you should use parameters, i.e. something like
SELECT ... WHERE column IN (?,?)
This is not only an easy approach, but also means that if somebody puts a single-quote in the value they give you, the form of your query can't be altered - that's how SQL Injection security attacks happen.
If you have values in the same column of another table you coud use a select query
select '''' + cast(ValueColumn as nvarchar) + '''' as QuotedVal from MyTable
and then do your copy/paste
I have a database in SQL Server containing a column which needs to contain Unicode data (it contains user's addresses from all over the world e.g. القاهرة for Cairo)
This column is an nvarchar column with a collation of database default (Latin1_General_CI_AS), but I've noticed data inserted into it via SQL statements containing non English characters and displays as ?????.
The solution seems to be that I wasn't using the n prefix e.g.
INSERT INTO table (address) VALUES ('القاهرة')
Instead of:
INSERT INTO table (address) VALUES (n'القاهرة')
I was under the impression that Unicode would automatically be converted for nvarchar columns and I didn't need this prefix, but this appears to be incorrect.
The problem is I still have some data in this column which appears as ????? in SQL Server Management Studio and I don't know what it is!
Is the data still there but in an incorrect character encoding preventing it from displaying but still salvageable (and if so how can I recover it?), or is it gone for good?
Thanks,
Tom
To find out what SQL Server really stores, use
SELECT CONVERT(VARBINARY(MAX), 'some text')
I just tried this with umlauted characters and Arabic (copied from Wikipedia, I have no idea) both as plain strings and as N'' Unicode strings.
The results are that Arabic non-Unicode strings really end up as question marks (0x3F) in the conversion to VARCHAR.
SSMS sometimes won't display all characters, I just tried what you had and it worked for me, copy and paste it into Word and it might display it corectly
Usually if SSMS can't display it it should be boxes not ?
Try to write a small client that will retrieve these data to a file or web page. Check ALL your code if there are no other inserts or updates that might convertthe data to varchar before storing them in tables.