[Okta Webinar] Learn how to a build a cloud-first strategyRegister Now

x
  • Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 752
  • Last Modified:

See invisible control character in varchar field

Every once in awhile someone seems to enter an invisible control character in a varchar field through my application.  When the dataset containing this record is selected and loaded into another application, problems occur.  I never know what the actual character is, but the len() function reveals more characters than I can acutally see.  It would be nice if I could see these invisilbe control characters by running a select statement in SQL Query Analyzer.

QUESTION:  When running a select statement in Query Analyzer against a varchar or char field, is there a way to also see the invisible characters, e.g. control characters, carriage returns, new line, etc.
0
rlsokoloff
Asked:
rlsokoloff
1 Solution
 
rlsokoloffAuthor Commented:
I meant to post this question in the Microsoft SQL section.  We use Microsoft SQL.
0
 
Guy Hengel [angelIII / a3]Billing EngineerCommented:
you could use the sp_hexstring procedure to look at the hex representation of the characters:
http://www.awprofessional.com/articles/article.asp?p=25288&seqNum=7&rl=1

the normal space id ascii(32), ie hex(2D)

0
 
rlsokoloffAuthor Commented:
I'm not sure how this sp_hexstring procedure would be useful to my question.  All it seems to do is take an integer represented as a varchar(10) and returns the hexidecimal representation of the integer.   I don't believe this answers my question.  Do you have more info?
0
Get free NFR key for Veeam Availability Suite 9.5

Veeam is happy to provide a free NFR license (1 year, 2 sockets) to all certified IT Pros. The license allows for the non-production use of Veeam Availability Suite v9.5 in your home lab, without any feature limitations. It works for both VMware and Hyper-V environments

 
nmcdermaidCommented:
>> When the dataset containing this record is selected and loaded into another application, problems occur

The best place to do it is probably whatever you are using to load the data. This is called a 'data cleansing' step.

In answer to your question, here is a way to find non-printing chracters:

SELECT *
FROM Table
WHERE CHARINDEX(CHAR(31), Field1) > 0

This particular select should find all records where Field1 contains char(31) - a non printing character.



SELECT *
FROM Table
WHERE (
CHARINDEX(CHAR(31), Field1) > 0
OR
CHARINDEX(CHAR(30), Field1) > 0
OR
CHARINDEX(CHAR(29), Field1) > 0
OR
CHARINDEX(CHAR(28), Field1) > 0
)


This one will find records that contain CHAR 31,30,29 or 28

As you can see you need to extend this for all the other non printable characters - all the way down to zero, and all the way from 128 to 256

I'm sure there are a number of smarter ways to do it but this way is self explanatory.

So how on earth do people get non-printing characters in there?

0
 
mnrzCommented:
hi
maybe there is no control character and users have entered unicode characters and this cause its length apear more that usual. however if you sure there is control characters have been entered you can replace with any other char you know.
0
 
nmcdermaidCommented:
True... first verify what the extra characters are... could they just be spaces?
0
 
rlsokoloffAuthor Commented:
Thanks for your comments!  I will explore the suggestions in more detail.

I have no idea how they got non-printing characters in there.  They must be hitting control something when typing info into  a textbox that then gets copied to the corresponding varchar field in the SQL Server database.  It rarely happens.  I assume it's a control character, because it termintates the rest of the record in the recordset that my applciation copies into a 3d-party spreadsheet (fpSpread from Farpoint).  It is not a space for sure.  But when I apply a length function to the problem field in the record, it clearly shows the length is longer than the number of visible characters.

I'd like to verify what the extra charactes are--that was my question.  They are not spaces.

0
 
Anthony PerkinsCommented:
>>I'd like to verify what the extra charactes are<<
That was what angelIII was trying to help you with.
0
 
rlsokoloffAuthor Commented:
Thank you for the responses.  I don't think any of the answers really fit, although nmcdermaid came closest, bringing to my attention the charindex function().  

I believe the problem occurs with the last character in the problem record of the problem field.  The next time I encounter the problem, I will do something like the following to ID the maverick character.....

     select ascii( right(fieldname, 1))
     from tablename
     order by ascii(right(fieldname, 1))

where the actual names are substituted for fieldname and table.

0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

Tackle projects and never again get stuck behind a technical roadblock.
Join Now