Why use the 'copy' command?

[TomazZ]

I don't get it - how can you have a chr(185) in us7ascii database anyway

[abhaysk]

Originally posted by TomazZ
I don't get it - how can you have a chr(185) in us7ascii database anyway

WW15_DBA> select * from NLS_DATABASE_PARAMETERS  where PARAMETER = 'NLS_CHARACTERSET';

PARAMETER                      VALUE
------------------------------ ----------------------------------------
NLS_CHARACTERSET               US7ASCII

WW15_DBA> select kurst,FCURR,TCURR,GDATU, ascii(substr(GDATU,3,3)) "Ascii Value of GDATU" from temp_ytcurr
  2  where kurst='M' and FCURR='GRD' and TCURR='USD' and GDATU like '19%90320';

KURS FCURR TCURR GDATU    Ascii Value of GDATU
---- ----- ----- -------- --------------------
M    GRD   USD   19990320                  185
M    GRD   USD   19990320                  185
M    GRD   USD   19990320                   57
M    GRD   USD   19990320                   57

7-Bit Characterset will have range of binary values from -127 to +127.

the range of values from -127 to -1 will be mirror image of 1 to 127..i mean same charactes/numbers repeated.

Abhay.

[TomazZ]

Originally posted by abhaysk
7-Bit Characterset will have range of binary values from -127 to +127.

Actually, 7-bit characterset should have only 0-127 character values.
2^7=128
I look that up on metalink:

Data in us7ascii is 8-bit, but the point is that the value of the 8th bit is undefined. All our software can do is assume that data is in the encoding scheme you say it is. If it is not, then you can not expect things to work correctly. If you have the database character set specified as US7ASCII and NLS_LANG as (for example) American_America.US7ASCII then since both are the same, no character set conversion will take place. If you now 'cheat' and insert a character with a byte value 164 (which is for example an 'n tilde lowercase' in WE8PC850), then that is the byte value that is stored, and that is the byte value that is returned if you query it. However, any string processing done on the data (for example UPPER, LOWER, INITCAP SQL functions, or character validation done by Developer in a CHAR field) will process the byte as if it were byte value 36 (being 164-128) since you have told the software that the data is in US7ASCII.

...

the point is that the database encoding scheme (specified with the CREATE DATABASE command) must be one that defines all the characters you need to handle in the specific application.

Ther is no problem in copy command with 7-bit charactersets except if the 7-bit character has another bit in the pocket

[abhaysk]

Originally posted by TomazZ
Ther is no problem in copy command with 7-bit charactersets except if the 7-bit character has another bit in the pocket

This is what I said in my previous post ( Ofcourse I should admit I had thought wrongly the range of values, however with 8th bit undefined we can think of it as SIGN bit as well )

"COPY work fine with what so ever....only exception is for Characterset US7ASCII or any 7-bit characterset when ascii values are above 127.For this case it sucks."

[TomazZ]

Yep, that's what you said. Sorry and thanks for interesting information.
Still, I would say the fault is that database lets you insert 7-bit character with value over 127 in the first place.
And the copy command is probably not the only victim of this fault.

[abhaysk]

Originally posted by TomazZ
Still, I would say the fault is that database lets you insert 7-bit character with value over 127 in the first place.
And the copy command is probably not the only victim of this fault.

DB lets you insert -> agreed thats not the one it should as its a 7-bit charset.

Ok, now try "select chr(340) from dual;" in any of the 8-Bit characterset you will know the reason why i said -127 to +127 or rather you can assume 127+ as starting from 0+ values ( but this however differs in actual storage of Binary Values )....


Did I say COPY is only victim of this fualt?

Abhay.

[TomazZ]

Originally posted by abhaysk

Ok, now try "select chr(340) from dual;" in any of the 8-Bit characterset you will know the reason why i said -127 to +127 or rather you can assume 127+ as starting from 0+ values ( but this however differs in actual storage of Binary Values )....

It's doing mod 256 (wraps around the byte discarding overflow). And what's the point?
I don't get you

Did I say COPY is only victim of this fualt?

I don't believe you did.
Have I said you said something like that?