Want to protect your cyber security and still get fast solutions? Ask a secure question today.Go Premium

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

Some chars are not accepted by SQL

In my web project I have a large note field that should accept comments by the user. But I have found that some characters will not be accepted by SQL - one of those is the appostrophe "'". I also use a simple encryption routine that produces a lot of non-printable characters as the output and they too are sometimes rejected by SQL. I would think a text field should accept anything, but not true. My note field is very important and I cant limit what the user types in. How do a get around this problem?
0
rblackwell
Asked:
rblackwell
  • 3
  • 2
1 Solution
 
nigelrivettCommented:
It will accept ' but in the query you have to send '' instead.

text field only accepts ascii characters - if you want it to accept characters that are not within that codeset you need to store as unicode and define the field as ntext.
You also need to deal with unicode values in this feld whenever it is accesed or the data transferred.
0
 
nigelrivettCommented:
e.g.

insert tbl select 'gfhkf'gfhkg'

will fail

insert tbl select 'gfhkf''gfhkg'
will work.

For unicode try

select 'n'
and select N'n'
where n is the char in question. If it is a character set problem then the first one will translate the char.

0
 
rblackwellAuthor Commented:
Ok, this seems to make sense. Currently my PW field is set to nvarchar and it only accepts certain charaters. I changed it to ntext and my code would not authenticate anyone with any name, but as soon as I changed the field from ntext back to nvarchar the PW work (but still had the limitation). ??? Should I do something different in my code if the field is ntext? Sorry but i'm just a little confused by your second paragraph.
thanks
0
 
nigelrivettCommented:
What is the field supposed to hold - you only need ntext if the field needs to be more than 4000 chars.
text fields are a lot more difficult to manipulate than chars so should only be used if necessary.

The nvarchar field will accept any unicode character - if it is not then there is probably a problem with your interface. The field needs to be handled as unicode everywhere.

My last paragraph was pointing out that

insert nvarcharfield select 'ghjk'
will translate any non ascii characters whereas
insert nvarcharfield select N'ghjk'
will retain them
0
 
rblackwellAuthor Commented:
You pointed my in the correct direction. I found my com object was casting the incoming variables as Strings which of course do not hold Unicode inforation. Thanks for the lead.
0

Featured Post

Keep up with what's happening at Experts Exchange!

Sign up to receive Decoded, a new monthly digest with product updates, feature release info, continuing education opportunities, and more.

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