Showing posts with label characters. Show all posts
Showing posts with label characters. Show all posts

Tuesday, March 27, 2012

Are Blank String and String with only Space characters equal to each other? They should not be!!

I have a table called Table_1

Table_1
--
a varchar(10),
b varchar(20)

and Column a is the Primary Key.

INSERT INTO Table_1
(a ,b)
VALUES
('' , 'BLANK STRING')

INSERT INTO Table_1
(a ,b)
VALUES
(' ' ,'4 SPACES')

When i execute this Insertions, it inserts the First Record but on the Second one it gives Violation of Uniqueness

(1 row(s) affected)
Msg 2627, Level 14, State 1, Line 9
Violation of PRIMARY KEY constraint 'PK_Table_1'. Cannot insert duplicate key in object 'dbo.Table_1'.
The statement has been terminated.

My Questions is that; HOW can a Blank String or a String with 4(or any number) space charcters in it can be EQUAL? In my opinion they should not be regarded as the same! Is there a solution to this issue? That's not the case in Oracle Database.

Thanks for your help!

Regards,
Cem

According to ANSI standards (or is it SQL Server's implementation of ANSI...), anyway, for sorting purposes, leading blanks are ignored. (And Primary Keys are 'sorted'...)

Try these two statements, the first will provide the 'right' answer, and the second will provide the 'real' answer.


SELECT len( (replicate( ' ', 4 )) )
SELECT datalength( (replicate( ' ', 4 )) )

|||

You should check the setting of SET ANSI_PADDING. If you want behavior such as you find in ORACLE, you will need SET ANSI_PADDING ON. That way trailing blanks will not be trimmed from your VARCHAR insert statements.

http://msdn2.microsoft.com/en-us/library/ms187403.aspx

Dan

Thursday, March 22, 2012

arabic characters are not saved (was "A serious problem ...- plz. help"

Dear all ..
i have a serious problem & all ur comments will be appreciated..

i have bought an ASP .NET publishing tool which i receieved an sql script with it to execute on either Ms sql server or MSDE .

i executed it on MSDE as i don't have Ms sql server on my windows dedicated server .

I wanted the tool for publishing (Arabic Language)content for a highly traffic soccer website..

After executing the sql script i tested the tool but i found arabic characters are not saved when i add articles .. they were saved as question marks (??).

so i re-executed the sql script on a new db after modifying every code containg (varchar) to (nvarchar) to support unicode & thus arabic.

it worked & i succeeded in saving arabic articles

BUT >>>>>>>>>>>>>

i found that only short arabic articles r saved fine while any article that reaches around (1 microsoft word page) is not saved well with arabic characters but saved as question marks ( ? ) .. !!

=======

so i checked the db tables using ASP.NET Enterprise manager & i found that

the field of article has (ntext) & infront of it number 16 ..

it seems that the (ntext) has a limit to wt it can save ..

so i believe there's a way which i don't know to make the (ntext) accepts long articles entry .

========

Here's the code in the original sql script i received with the tool & i hope u can guide me in details to any modification to do so that the ntext limit is raise to save any long arabic article.

========

code :

CREATE TABLE [dbo].[xlaANMarticles] (
[articleid] [int] IDENTITY (1, 1) NOT NULL ,
[posted] [nvarchar] (50) NOT NULL ,
[lastupdate] [nvarchar] (50) NOT NULL ,
[headline] [nvarchar] (350) NOT NULL ,
[headlinedate] [nvarchar] (255) NOT NULL ,
[startdate] [nvarchar] (50) NOT NULL ,
[enddate] [nvarchar] (50) NOT NULL ,
[source] [nvarchar] (255) NOT NULL ,
[summary] [nvarchar] (3000) NOT NULL ,
[articleurl] [nvarchar] (1000) NOT NULL ,
[article] [ntext] NOT NULL ,
[status] [tinyint] NOT NULL ,
[autoformat] [nvarchar] (50) NOT NULL ,
[publisherid] [int] NOT NULL ,
[clicks] [int] NOT NULL ,
[editor] [int] NOT NULL ,
[relatedid] [nvarchar] (2000) NOT NULL ,
[isfeatured] [nvarchar] (10) NULL ,
[keywords] [nvarchar] (255) NULL ,
[description] [nvarchar] (255) NULL
) ON [PRIMARY] TEXTIMAGE_ON [PRIMARY]

i highlighted the specific column for the article field with red color ..

i tried making it (nvarchar) but the sql manager i use saud it can't be done coz. there has to be a field for TEXTIMAGE coz. it's set to be (on) in the code.

waiting for ur help plz. ... i am desperate .. :confused:Masry-

I maximum length of NTEXT is 1,073,741,823 characters. I can't imagine a page of MS word document holding more than that limit. In addition, BOL says prefix the unicode character strings with N. You might want to try with N. Not sure what 16 means.|||The problem is that saving Arabic characters (like any unicode or 16 bit characters) requires a full 16 bit data path from begining to end. If any part of the path reverts back to 8 bit characters, then any character that isn't supported by the 16 bit to 8 bit translation will appear as a question mark.

Apparently something in the data path that handles the translation from Word documents larger than a given (roughly one page) threshold to a database column causes the data to pass through as 8 bit characters. The problem lies in isolating whatever that weak point is!

-PatP|||Masry,
BLOB values are not saved in row, but elsewhere in data file, unless you use sp_tableoption. The 16 in front of ntext column is only a pointer to where the actual ntext value is located.
But about your problem, I suggest to check the path that your data is traversing to be saved to DB. There might some variables or ... be used that cause the Unicode information be lost!
Regards,
Leila

Arabic and Far East text saving as

I have a database that captuers user comments, however when comments are
posted using either Arabic or Far East characters the only thing that shows
up is a series of ? marks. These question marks also appear through SQL
Reporting Services. This haapens when the text is added via ad-hoc insert
query or though a SP.
I can open SQL Management Studio, open the table and insert the Arabic or
Chinese character ditectly into the table and the Arabic or Chinese text
will appear correctly in SQL Reporting Services.
The system configuration is:
SQL 2005 Standard
Windows Server 2003 Standard SP1
The table fields are delcared as NVARCHAR and all the parameters in the SP
are NVARCHAR as well.
Any ideas on how to resolve this?
Thank you
Marc HensleyAre the comment strings preceded by the 'N' prefix? For example, see
http://support.microsoft.com/?kbid=239530. Though targeted to earlier
versions, it still applies to SQL Server 2005.
David Barber [MS]
SQL Server Documentation Team
This posting is provided "AS IS" with no warranties, and confers no rights
"Marc Hensley" <marc.hensley@.newsgroups.nospam> wrote in message
news:%23RYrtjGRGHA.2436@.TK2MSFTNGP11.phx.gbl...
> I have a database that captuers user comments, however when comments are
> posted using either Arabic or Far East characters the only thing that
shows
> up is a series of ? marks. These question marks also appear through SQL
> Reporting Services. This haapens when the text is added via ad-hoc insert
> query or though a SP.
> I can open SQL Management Studio, open the table and insert the Arabic or
> Chinese character ditectly into the table and the Arabic or Chinese text
> will appear correctly in SQL Reporting Services.
> The system configuration is:
> SQL 2005 Standard
> Windows Server 2003 Standard SP1
> The table fields are delcared as NVARCHAR and all the parameters in the SP
> are NVARCHAR as well.
> Any ideas on how to resolve this?
> Thank you
> Marc Hensley
>|||Thank You -- That is what it was. Sent the issue back to the ASP Guys to
correct.
Marc
"David Barber [MS]" <dbarber@.microsoft.com> wrote in message
news:exhfbjHRGHA.4572@.TK2MSFTNGP10.phx.gbl...
> Are the comment strings preceded by the 'N' prefix? For example, see
> http://support.microsoft.com/?kbid=239530. Though targeted to earlier
> versions, it still applies to SQL Server 2005.
> --
> David Barber [MS]
> SQL Server Documentation Team
> This posting is provided "AS IS" with no warranties, and confers no rights
> "Marc Hensley" <marc.hensley@.newsgroups.nospam> wrote in message
> news:%23RYrtjGRGHA.2436@.TK2MSFTNGP11.phx.gbl...
> shows
>sql

Wednesday, March 7, 2012

Application Roles ENCRYPT function Valid Password Characters

When I try to use the ODBC canonical ENCRYPT function for SP_SETAPPROLE, I
get an ODBC error when certain otherwise good characters are used in the
password. What characters are and are not allowed for passwords for
application roles while using the ENCRYPT function?You might ask me what is a good password? Here is a sample:
wZ726BcF_vR?goLVmxgsGLkZpqQbZ<Yfu<?L<t
RQzCa85c?"DXtI,QPbUtIyBSJbqF?
(without the line return)
"Chuck Hawkins" <charles.hawkins@.NOSPAMjenzabar.net> wrote in message
news:ebySvpBfFHA.3944@.TK2MSFTNGP10.phx.gbl...
> When I try to use the ODBC canonical ENCRYPT function for SP_SETAPPROLE, I
> get an ODBC error when certain otherwise good characters are used in the
> password. What characters are and are not allowed for passwords for
> application roles while using the ENCRYPT function?
>|||You can find the valid characters in the books online help
topic: Security Rules.
You can find the topic in the index under passwords, rules
for
-Sue
On Tue, 28 Jun 2005 15:49:06 -0400, "Chuck Hawkins"
<charles.hawkins@.NOSPAMjenzabar.net> wrote:

>When I try to use the ODBC canonical ENCRYPT function for SP_SETAPPROLE, I
>get an ODBC error when certain otherwise good characters are used in the
>password. What characters are and are not allowed for passwords for
>application roles while using the ENCRYPT function?
>|||Thank you, Sue. I went back and re-wrote my password generation script to
remove references to the unallowed characters mentioned in Security Rules
for passwords - []{}(),;?*! @..
I'm still having the problem with the ENCRYPT function. I execute:
sp_setapprole
@.rolename = 'TEST',
@.password = {Encrypt N
'ro111гPM0ci?TxmOK
e3qJDtSV?Xrи"S??D
k2?q6L?EvrvI1mOENycWpLvz
jL?3kn'}
--@.password = {Encrypt N 'easy'}
,@.encrypt = 'odbc'
go
And get:
[Microsoft][ODBC SQL Server Driver]Syntax error or access violation
I know I don't have a syntax error (other than an ugly password). When I
switch the TEST app role over to a password of 'easy', it works.
Am I supposed to put braces [] around the password somehow?
So the question remains, what characters are not allowed for passwords? I
know []{}(),;?*! @.. are not, but I don't have any of these.
Chuck
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:99a4c1p6996f5mklnjbq0hhmapjunkv95u@.
4ax.com...
> You can find the valid characters in the books online help
> topic: Security Rules.
> You can find the topic in the index under passwords, rules
> for
> -Sue
> On Tue, 28 Jun 2005 15:49:06 -0400, "Chuck Hawkins"
> <charles.hawkins@.NOSPAMjenzabar.net> wrote:
>
>|||Incidentally, here is the ugly password generation code:
set nocount on
declare @.counter int,
@.password varchar(128),
@.char char(1),
@.charindex int,
@.loop int
/* Unallowed characters:
! = 33
( = 40
) = 41
, = 40
* = 42
; = 59
? = 63
@. = 64
[ = 91
] = 93
{ = 123
} = 125
*/
select @.counter = 1, @.password = ''
while @.counter < 2
begin
--Restrict the password to 0-9, A-Z, and a-z
select @.loop = 1
while @.loop = 1
begin
select @.charindex = convert(int, rand() * 254)
if (@.charindex between 65 and 90 or @.charindex between 97 and 122)
and @.charindex not in (33,40,41,42,59,63,64,91,93,123,125)
--or @.charindex between 161 and 255 or @.charindex between 130 AND 140
select @.loop = 0
end
--Accumulate characters for password string
select @.char = char(@.charindex)
select @.password = @.password + @.char
select @.counter = @.counter + 1
end
while @.counter < 4
begin
--Restrict the password to 0-9, A-Z, and a-z
select @.loop = 1
while @.loop = 1
begin
select @.charindex = convert(int, rand() * 254)
if (@.charindex between 48 and 57 or @.charindex between 65 and 90 or
@.charindex between 97 and 122)
and @.charindex not in (33,40,41,42,59,63,64,91,93,123,125)
--or @.charindex between 161 and 255 or @.charindex between 130 AND 140
select @.loop = 0
end
--Accumulate characters for password string
select @.char = char(@.charindex)
select @.password = @.password + @.char
select @.counter = @.counter + 1
end
while @.counter < 5
begin
--Restrict the password to 0-9
select @.loop = 1
while @.loop = 1
begin
select @.charindex = convert(int, rand() * 254)
if @.charindex between 48 and 57 --or @.charindex between 65 and 90 or
@.charindex between 97 and 122
and @.charindex not in (33,40,41,42,59,63,64,91,93,123,125)
--or @.charindex between 161 and 255 or @.charindex between 130 AND 140
select @.loop = 0
end
--Accumulate characters for password string
select @.char = char(@.charindex)
select @.password = @.password + @.char
select @.counter = @.counter + 1
end
while @.counter < 10
begin
-- Restrict the password to NOT 0-9, A-Z, and a-z
select @.loop = 1
while @.loop = 1
begin
select @.charindex = convert(int, rand() * 254)
if --@.charindex between 48 and 57 or @.charindex between 65 and 90 or
@.charindex between 97 and 122
--or
(@.charindex between 161 and 255 or @.charindex between 130 AND 140)
and @.charindex not in (33,40,41,42,59,63,64,91,93,123,125)
select @.loop = 0
end
--Accumulate characters for password string
select @.char = char(@.charindex)
select @.password = @.password + @.char
select @.counter = @.counter + 1
end
while @.counter < 11
begin
--Restrict the password to 0-9
select @.loop = 1
while @.loop = 1
begin
select @.charindex = convert(int, rand() * 254)
if @.charindex between 48 and 57 --or @.charindex between 65 and 90 or
@.charindex between 97 and 122
and @.charindex not in (33,40,41,42,59,63,64,91,93,123,125)
--or @.charindex between 161 and 255 or @.charindex between 130 AND 140
select @.loop = 0
end
--Accumulate characters for password string
select @.char = char(@.charindex)
select @.password = @.password + @.char
select @.counter = @.counter + 1
end
while @.counter < 129
begin
--Restrict the password to 0-9, A-Z, and a-z
select @.loop = 1
while @.loop = 1
begin
select @.charindex = convert(int, rand() * 254)
if (@.charindex between 48 and 57 or @.charindex between 65 and 90 or
@.charindex between 97 and 122
or @.charindex between 161 and 255 or @.charindex between 130 AND 140)
and @.charindex not in (33,40,41,42,59,63,64,91,93,123,125)
select @.loop = 0
end
--Accumulate characters for password string
select @.char = char(@.charindex)
select @.password = @.password + @.char
select @.counter = @.counter + 1
end
select RTRIM(@.password) AS Password
"Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
news:99a4c1p6996f5mklnjbq0hhmapjunkv95u@.
4ax.com...
> You can find the valid characters in the books online help
> topic: Security Rules.
> You can find the topic in the index under passwords, rules
> for
> -Sue
> On Tue, 28 Jun 2005 15:49:06 -0400, "Chuck Hawkins"
> <charles.hawkins@.NOSPAMjenzabar.net> wrote:
>
>|||What I've discovered:
The password characters are not allowed for or the canonical ENCRYPT functio
n does not work with characters with the following ASCII codes:
(33,40,41,42,59,63,64,91,93,123,125,130,
132,133,134,135,136,137,139,161,162,
166,167,168,169,171,172,173,174,175,176,
177,180,182,184,187,188,189,190,191,
215,247)
Further, in order for the ENCRYPT function to work, the password cannot be m
ore than 64 characters (vice 128 allowed in Security Rules).
All that said, it still doesn't work. When I enter the following code, I can
not get the SP_SETAPPROLE to work:
exec sp_dropapprole 'TEST_APPROLE'
go
exec sp_addapprole
@.rolename = 'TEST_APPROLE',
@.password = 'rwq4?37ctEPn0izwhJ6dq
dACSZcfmfia?fWG
'
go
sp_setapprole
@.rolename = 'TEST_APPROLE',
@.password = {Encrypt N 'rwq4?37ctEPn0izwhJ6dq
dACSZc
fmfia?fWG'}
--@.password = {Encrypt N 'easy'}
,@.encrypt = 'odbc'
go
Server: Msg 2764, Level 16, State 1, Procedure sp_setapprole, Line 41
Incorrect password supplied for application role 'TEST_APPROLE'.
So the question remains, what are valid password characters for application
roles in order for the ENCRYPT function to work?
And now we have a new question, why does the ENCRYPT function limit you to 6
4 characters? I have my suppositions but I'd love to hear from someone who k
nows.
Chuck Hawkins
"Chuck Hawkins" <charles.hawkins@.NOSPAMjenzabar.net> wrote in message news:OUXAtKKfFHA.572@.T
K2MSFTNGP15.phx.gbl...
> Thank you, Sue. I went back and re-wrote my password generation script to
> remove references to the unallowed characters mentioned in Security Rules
> for passwords - []{}(),;?*! @..
> I'm still having the problem with the ENCRYPT function. I execute:
>
> sp_setapprole
> @.rolename = 'TEST',
> @.password = {Encrypt N
> 'ro111гPM0ci?TxmOK
e3qJDtSV?Xrи"S??
Dk2?q6L?EvrvI1mOENycWpLv
zjL?3kn'}
> --@.password = {Encrypt N 'easy'}
> ,@.encrypt = 'odbc'
> go
>
> And get:
> [Microsoft][ODBC SQL Server Driver]Syntax error or access violatio
n
>
> I know I don't have a syntax error (other than an ugly password). When I
> switch the TEST app role over to a password of 'easy', it works.
>
> Am I supposed to put braces [] around the password somehow?
>
> So the question remains, what characters are not allowed for passwords? I
> know []{}(),;?*! @.. are not, but I don't have any of these.
>
> Chuck
>
> "Sue Hoegemeier" <Sue_H@.nomail.please> wrote in message
> news:99a4c1p6996f5mklnjbq0hhmapjunkv95u@.
4ax.com...
>
>