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.
Who is Participating?

Improve company productivity with a Business Account.Sign Up

nmcdermaidConnect With a Mentor Commented:
>> 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:

FROM Table

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

FROM Table
CHARINDEX(CHAR(31), Field1) > 0
CHARINDEX(CHAR(30), Field1) > 0
CHARINDEX(CHAR(29), Field1) > 0
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?

rlsokoloffAuthor Commented:
I meant to post this question in the Microsoft SQL section.  We use Microsoft SQL.
Guy Hengel [angelIII / a3]Billing EngineerCommented:
you could use the sp_hexstring procedure to look at the hex representation of the characters:

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

Easily Design & Build Your Next Website

Squarespace’s all-in-one platform gives you everything you need to express yourself creatively online, whether it is with a domain, website, or online store. Get started with your free trial today, and when ready, take 10% off your first purchase with offer code 'EXPERTS'.

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?
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.
True... first verify what the extra characters are... could they just be spaces?
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.

Anthony PerkinsCommented:
>>I'd like to verify what the extra charactes are<<
That was what angelIII was trying to help you with.
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.

Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.