Redian新闻
>
java数据库读取错误,请教
avatar
java数据库读取错误,请教# Java - 爪哇娇娃
W*9
1
在某女子劳教所里,采访从良小姐阿云怎么走向“新生”,她正戒烟,她说,这比戒男
人还难。她比其他风尘女子都健谈,因为唇舌寂寞,又抽不了烟,所以嘴贫,常会蹦出
一些闪光的句子,有关男女有关情色。我特地把她一些语句摘录下来,让我们垃圾里找
黄金吧。
1、喜欢女人的男人都容易成功。一个男人如果不好色很难成功。睾丸是男人生命
发电站。这样的论调,日本一个著名的妈妈桑好象也说过。
2、找过她的男人多是西装打扮,很正式的,喜欢下班时间,大约5点左右,不是常
人想象的午夜。一般是开着手机,如果有电话来,多说:“我在开会!”所谓衣冠然后
禽兽。
3、很多男人喜欢把嫖资扔到床上,重点是一个“扔”字,像小费一样埋在枕头下
的很少。嫖客是不做绅士的,裤子都脱了,还装什么文明?
4、嫖客一般不接吻,怕得病,她也不喜欢,因为嘴唇比阴唇挑剔。因为不爱。爱
才吻
5、曾寂寞无聊随便打电话给10个男人演戏说:“你好坏,是陈经理吗?昨天晚上…
…”结果有9个男人顺水推舟地说:“哦,是,我是陈先生!”其中一个因为身边带“干
粮”(太太),所以否认自己姓陈,不过事后又悄悄打过来此地无银地说:“我是陈经理
,刚才……”
6、没有一个男人喜欢女下男上的传统体位,因为家里都用腻了。
7、没有一个男人不问:“爽吧?”没有一个男人不喜欢被表扬他的老二举世无双硕
大无朋。男人的自尊其实比“老二”还脆弱,男人面子比屁股大。
8、如果要男人快点,小云的经验是,抱紧他说“最近风声比较紧”,男人一紧张
就早泄,这是她所乐见的,很有成就感,不一定有快感。
9、浪叫是硬道理。很多男人找她就是让耳朵舒服。肉麻是好的。男人不怕肉麻。
10、男人喜欢听她说“我要”,不过没有人喜欢听她说“我还要。”
11、她喜欢瘦的多腿毛的男人,不过,这纯个人喜好而已。小姐是要淡化个人口味
的。
12、事后男人一般不洗澡,因为怕湿湿的回去。但是,多会洗脸和下体。
13、男人喜欢周一到周四光顾,特别周五,她的生意清淡,因为很多男人都集中在
周末过夫妻生活,怕晚上回去透支身体被妻子察觉。
14、要听话,但是身体得“小有挣扎”,男人不喜欢太讨好的主动,适当忸怩作态
会让男人更兴奋。或者打扮成清纯的大学生或者护士,男人喜欢演戏做前戏。
15、说一些自己过去的性花絮,男人会听得津津有味热血沸腾。
16、有时偷偷开小差睁开眼睛,男人也会害羞的,甚至恼羞成怒,所以尽量都闭目
哼哈。“闭上眼睛就是天黑”,写这句歌词的男人太厉害!
17、男人进卫生间的时候,不要跟进去。不做那事情的时候,要保护对方隐私。
18、不要抓对方的背。怕留有指痕,在外面偷吃的男人,很奇怪都有一个疑神疑鬼
的太太。不要提他的太太,这会大煞风景。
19、纽扣比拉链更能调动男人的高昂情绪。
20、动手动脚是男人的事,女人只用眼神。
21、手背比手心更撩人。下巴比双唇更刺激。
22、把头发弄乱。拨乱反正是男人的事情。
23、叫他是流氓比说他是君子更得体。
24、男人床上的话比酒桌上的话更不可信。
25、做爱跟唱歌、走猫步一样,要饿着肚子。
26、不是美女也要做蛇,两只手臂不能闲着。男人喜欢缠绕之美。
27、不要动他的衣服、手机。就好比事后不要去碰他的身体一样。
28、会吃鸡的先生一般没有情人。
29、不要感动,多激动。江湖没有朋友。
30、女人对男人也会腻的。女人变心会更狠
avatar
c*a
2
怎么会这样呢?错误是这样的
java.sq.SQLException: Communication failure during handshake.
Is there a server:info9.vub.ac.be:3306?
前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be
请教
avatar
c*a
3
by the way , mysql database

【在 c***a 的大作中提到】
: 怎么会这样呢?错误是这样的
: java.sq.SQLException: Communication failure during handshake.
: Is there a server:info9.vub.ac.be:3306?
: 前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be
: 请教

avatar
f*g
4

It the problem reproduceable?
前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be

【在 c***a 的大作中提到】
: by the way , mysql database
avatar
xt
5

Sir, your question is dumb as your posts in you-know-what
board. :-)
I suggest checking the meaning of CommunicationException
before asking.

【在 f*****g 的大作中提到】
:
: It the problem reproduceable?
: 前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be

avatar
f*g
6

My question makes more sense than you. The guy got the exception
during reading data. That is probably a network failure. If it is not
reproducable, or say, the network is recovered, then it is a network
failure problem. If it is reproduceable, or say the network has no
probelm, that could be a MySQL protocol related problem (JDBC's,
or even MySQL's).

【在 xt 的大作中提到】
:
: Sir, your question is dumb as your posts in you-know-what
: board. :-)
: I suggest checking the meaning of CommunicationException
: before asking.

avatar
A*o
7
我怀疑是没有关Connection,这个连接是个佐证,或许可以帮忙。
http://mail.opencms.org/pipermail/opencms-dev/2003q2/005030.html

前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be

【在 c***a 的大作中提到】
: 怎么会这样呢?错误是这样的
: java.sq.SQLException: Communication failure during handshake.
: Is there a server:info9.vub.ac.be:3306?
: 前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be
: 请教

avatar
f*g
8

Then you should have a speicfic exception message like "too many
connections" or "maximum of connections reached"...
前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be

【在 A**o 的大作中提到】
: 我怀疑是没有关Connection,这个连接是个佐证,或许可以帮忙。
: http://mail.opencms.org/pipermail/opencms-dev/2003q2/005030.html
:
: 前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be

avatar
xt
9

Come on! It doesn't happen with some commercial DBMS and you
expect that kind of friendly error message with an open source
freeware?

【在 f*****g 的大作中提到】
:
: Then you should have a speicfic exception message like "too many
: connections" or "maximum of connections reached"...
: 前面的数据读的好好的.读到一半,就上面那样了。而且我的数据库放在info9.vub.ac.be

avatar
f*g
10

Do you ever use MySQL and its Connector/J?

【在 xt 的大作中提到】
:
: Come on! It doesn't happen with some commercial DBMS and you
: expect that kind of friendly error message with an open source
: freeware?

avatar
xt
11

I only use commercial DBMS, which is already
free to me.

【在 f*****g 的大作中提到】
:
: Do you ever use MySQL and its Connector/J?

avatar
c*g
12
Commerical does not mean high quality. Sybase jconnection 5.2
sucks. My boss is a big Sybase fan, and I just don't get it.
People say oracl sucks,but at least their documentation is good.
Sybase has the worst documentation and online forum i ever seen.

【在 xt 的大作中提到】
:
: I only use commercial DBMS, which is already
: free to me.

avatar
xt
13

Quit complaining about Sybase. If you like Oracle, you should try
this:
define a table with a field like "foo CHAR(32)"
then use your JDBC to insert a row, set foo to be "hello".
Then use Oracle JDBC driver to retrieve it, with foo='hello'
See what you get.
We have been using JConnect5 all the time, except before
2001. We never had any surprises like this. DB2 has some,
Oracle has some.

【在 c**g 的大作中提到】
: Commerical does not mean high quality. Sybase jconnection 5.2
: sucks. My boss is a big Sybase fan, and I just don't get it.
: People say oracl sucks,but at least their documentation is good.
: Sybase has the worst documentation and online forum i ever seen.

avatar
w*t
14
Hi xt,
I am interested in what you posted here (I suppose I should see sth weird
happen)
however, after testing, I did not notice anything wrong - something I ignored?
I used oracle9i DB, and 9ias(9.0.3)
table:
CREATE TABLE MYTABLE
(
FOO CHAR(32)
)
used jdbc to insert and retrieve (used PreparedStatement)
avatar
xt
15

ignored?
Sybase, DB2, Oracle all suck in JDBC documentation.
Maybe that problem is already fixed. Try Oracle thin driver. What happens is
that
if you insert a string less than 32 long, the DBMS will automatically append
white
space to that string and then store into DB. There is nothing wrong with this
behaviour. However, when you query that table with the original string you
used,
you will not get anything back, unless you append white space to make that
string
32 long.
OK, there is nothing wr

【在 w******t 的大作中提到】
: Hi xt,
: I am interested in what you posted here (I suppose I should see sth weird
: happen)
: however, after testing, I did not notice anything wrong - something I ignored?
: I used oracle9i DB, and 9ias(9.0.3)
: table:
: CREATE TABLE MYTABLE
: (
: FOO CHAR(32)
: )

avatar
w*r
16
come on, you guys are complainning about oracle, that
darn piece of dbms's JDBC is much better implemented comparing
to most others. I am using TeraData everyday, all kinds of issues
comes from the JDBC part. I was originally thought the company
like NCR whose customers usually pay hundreds of thousands of
dollars each year for just single node support should have a much better
implementation of JDBC, guess what? their own JDBC driver
cannot even parse some the legitimated SQL statement which
ru

【在 xt 的大作中提到】
:
: ignored?
: Sybase, DB2, Oracle all suck in JDBC documentation.
: Maybe that problem is already fixed. Try Oracle thin driver. What happens is
: that
: if you insert a string less than 32 long, the DBMS will automatically append
: white
: space to that string and then store into DB. There is nothing wrong with this
: behaviour. However, when you query that table with the original string you
: used,

avatar
w*t
17
I see - what you described still exists in 9i - thanks
but this is NOT a bug - in my opinion - and I actually would expect this kind
of behavior if you use fixed length of string def.
if you want variable length, you should go with varchar -- just my opinion
regarding jdbc driver overall - oracle sucks, even though it's much better
than some other dbms driver, it still sucks. Only diff is that other DB driver
sucks "bigger" time. :)
however, we have to live with that - I guess

in
this
the

【在 xt 的大作中提到】
:
: ignored?
: Sybase, DB2, Oracle all suck in JDBC documentation.
: Maybe that problem is already fixed. Try Oracle thin driver. What happens is
: that
: if you insert a string less than 32 long, the DBMS will automatically append
: white
: space to that string and then store into DB. There is nothing wrong with this
: behaviour. However, when you query that table with the original string you
: used,

avatar
xt
18

Honestly I feel Sybase and IBM JDBC are much better. Oracle JDBC is not good.
I have no idea of NCR's Terabyte, since it is even more unpopular than
Sybase ASE.

【在 w*r 的大作中提到】
: come on, you guys are complainning about oracle, that
: darn piece of dbms's JDBC is much better implemented comparing
: to most others. I am using TeraData everyday, all kinds of issues
: comes from the JDBC part. I was originally thought the company
: like NCR whose customers usually pay hundreds of thousands of
: dollars each year for just single node support should have a much better
: implementation of JDBC, guess what? their own JDBC driver
: cannot even parse some the legitimated SQL statement which
: ru

avatar
xt
19

kind
You can argue this way, but I do not agree. Well, even I agree with you, how
come
their own SQL Plus has different behaviour from JDBC on the very same SQL
string?
This stupid behaviour only happens with Oracle. I do not think it is in
accordance with SQL92 standard.

【在 w******t 的大作中提到】
: I see - what you described still exists in 9i - thanks
: but this is NOT a bug - in my opinion - and I actually would expect this kind
: of behavior if you use fixed length of string def.
: if you want variable length, you should go with varchar -- just my opinion
: regarding jdbc driver overall - oracle sucks, even though it's much better
: than some other dbms driver, it still sucks. Only diff is that other DB driver
: sucks "bigger" time. :)
: however, we have to live with that - I guess
:
: in

avatar
w*r
20
HOHO... It is TeraData... not TeraByte yah.. well, the problem for
our company is that the data is HUGE.... none of DB2/Ora/Sybase would
be able to accomodate the performance need to host the data and the
daily queries run through it..

【在 xt 的大作中提到】
:
: kind
: You can argue this way, but I do not agree. Well, even I agree with you, how
: come
: their own SQL Plus has different behaviour from JDBC on the very same SQL
: string?
: This stupid behaviour only happens with Oracle. I do not think it is in
: accordance with SQL92 standard.

avatar
x*n
21
LET ME EXPLAIN WHERE YOU WERE WRONG, XT.
You used CHAR(32) instead of VARCHAR(32).
Don't expect CHAR(32) to behave like variable char, ok?
It's your fault, instead of Oracle. Unfornately you used your fault to say
Oracle sucks.
This happened before to you. You had a mistake in Java Specification and then
compained "Stupid IBM JDK".

【在 xt 的大作中提到】
:
: kind
: You can argue this way, but I do not agree. Well, even I agree with you, how
: come
: their own SQL Plus has different behaviour from JDBC on the very same SQL
: string?
: This stupid behaviour only happens with Oracle. I do not think it is in
: accordance with SQL92 standard.

avatar
w*r
22
hoho... XT又被鄙视了一把……………

【在 x***n 的大作中提到】
: LET ME EXPLAIN WHERE YOU WERE WRONG, XT.
: You used CHAR(32) instead of VARCHAR(32).
: Don't expect CHAR(32) to behave like variable char, ok?
: It's your fault, instead of Oracle. Unfornately you used your fault to say
: Oracle sucks.
: This happened before to you. You had a mistake in Java Specification and then
: compained "Stupid IBM JDK".

avatar
xt
23

then
Hi stupid,
Read my post carefully. Explain what CHAR(32) means, better bring up SQL92
standard. Also are you saying that the inconsistent behaviour between their
SQL Plus and JDBC is correct?

【在 x***n 的大作中提到】
: LET ME EXPLAIN WHERE YOU WERE WRONG, XT.
: You used CHAR(32) instead of VARCHAR(32).
: Don't expect CHAR(32) to behave like variable char, ok?
: It's your fault, instead of Oracle. Unfornately you used your fault to say
: Oracle sucks.
: This happened before to you. You had a mistake in Java Specification and then
: compained "Stupid IBM JDK".

avatar
xt
24

Let me explain what CHAR(32) means. CHAR(32) means a fixed length string
field as opposed what is defined by VARCHAR or CLOB etc. However, CHAR(32)
does not mean you have to make your value 32 long, but you cannot go beyond
32. In case you do not have 32 characters, DBMS will append white space
to it - which is what Oracle is doing as well. However, that does not mean
that when you retrieve the data, it should give you the white space it adds.
Obviously MS, IBM, Sybase and even Oracle SQL Plus

【在 x***n 的大作中提到】
: LET ME EXPLAIN WHERE YOU WERE WRONG, XT.
: You used CHAR(32) instead of VARCHAR(32).
: Don't expect CHAR(32) to behave like variable char, ok?
: It's your fault, instead of Oracle. Unfornately you used your fault to say
: Oracle sucks.
: This happened before to you. You had a mistake in Java Specification and then
: compained "Stupid IBM JDK".

avatar
x*n
25
http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/43059FE5F9575FB188256B41
006418C1/$FILE/32N0743T.PDF
Page 16-17.
Please don't blame others before carefully reading the spec.

Oracle

【在 xt 的大作中提到】
:
: Let me explain what CHAR(32) means. CHAR(32) means a fixed length string
: field as opposed what is defined by VARCHAR or CLOB etc. However, CHAR(32)
: does not mean you have to make your value 32 long, but you cannot go beyond
: 32. In case you do not have 32 characters, DBMS will append white space
: to it - which is what Oracle is doing as well. However, that does not mean
: that when you retrieve the data, it should give you the white space it adds.
: Obviously MS, IBM, Sybase and even Oracle SQL Plus

avatar
xt
26

http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/43059FE5F9575FB188256B41
There is nothing saying that when you store a shorter value into a CHAR field
you should get white spaces back, period. What's good for a database if it
changes the values you store when you retrieve?

【在 x***n 的大作中提到】
: http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/43059FE5F9575FB188256B41
: 006418C1/$FILE/32N0743T.PDF
: Page 16-17.
: Please don't blame others before carefully reading the spec.
:
: Oracle

avatar
x*n
27
You should read carefully the definition of collation and padding.
They determine the '=' of strings.
Oracle adhears to the standard, so are other vendors, and you criticize only
Oracle for your own fault.
The same thing happened before, which was why I pointed out.
Last time, for the posts of "Stupid IBM JDK",
IBM adhears to the specification, so are other vendors, and you criticized
only
IBM for your own mistake.
I know you still feel IBM sucks (which I don't care), but your starting point
was

【在 xt 的大作中提到】
:
: http://www.jtc1sc32.org/sc32/jtc1sc32.nsf/Attachments/43059FE5F9575FB188256B41
: There is nothing saying that when you store a shorter value into a CHAR field
: you should get white spaces back, period. What's good for a database if it
: changes the values you store when you retrieve?

avatar
xt
28

It is not my fault that JDBC returns a different value than their own SQL
Plus.
Sir, this is getting ridiculous. When I add a string into a CHAR(32) with DB2
then use their JDBC to retrieve it, it does NOT give me the padding. So what
*is* the standard? Please understand English!
point
IBM
IBM JDK sucks for sure. Last time I used a relatively complicated boolean
method
and used if( !complicatedMethod() ) {}. The method returned true and it went
into
the scope! Then I just changed to if( !(compl

【在 x***n 的大作中提到】
: You should read carefully the definition of collation and padding.
: They determine the '=' of strings.
: Oracle adhears to the standard, so are other vendors, and you criticize only
: Oracle for your own fault.
: The same thing happened before, which was why I pointed out.
: Last time, for the posts of "Stupid IBM JDK",
: IBM adhears to the specification, so are other vendors, and you criticized
: only
: IBM for your own mistake.
: I know you still feel IBM sucks (which I don't care), but your starting point

avatar
xt
29

Don't you think I know this part of the story? Just in case you
do not understand the situation, or totally are ignorant of Oracle
JDBC, let me give you an example:
Create a table with field foo (CHAR32)
Use JDBC, insert a row with foo="hello"
Use JDBC, search the table with foo="hello", you get NOTHING back
Use JDBC, search the table with foo="hello" plus 26 spaces you get
a row back.
Use SQL Plus, search the table with foo="hello" you get the record
back
Obviously this is a very small test ca

【在 x***n 的大作中提到】
: You should read carefully the definition of collation and padding.
: They determine the '=' of strings.
: Oracle adhears to the standard, so are other vendors, and you criticize only
: Oracle for your own fault.
: The same thing happened before, which was why I pointed out.
: Last time, for the posts of "Stupid IBM JDK",
: IBM adhears to the specification, so are other vendors, and you criticized
: only
: IBM for your own mistake.
: I know you still feel IBM sucks (which I don't care), but your starting point

avatar
w*r
30
你们两个吵吵吵吵吵,本来一个很简单的问题吵得这么复杂,随便找一个JDBC的implemen
tation出来都有一大堆的问题,XT提到的这个只是一个小问题而已,标准就是要space
padding,在对外的接口上这个padding应该是invisible, 吵什么吵?一个小bug,闹!

【在 xt 的大作中提到】
:
: Don't you think I know this part of the story? Just in case you
: do not understand the situation, or totally are ignorant of Oracle
: JDBC, let me give you an example:
: Create a table with field foo (CHAR32)
: Use JDBC, insert a row with foo="hello"
: Use JDBC, search the table with foo="hello", you get NOTHING back
: Use JDBC, search the table with foo="hello" plus 26 spaces you get
: a row back.
: Use SQL Plus, search the table with foo="hello" you get the record

avatar
c*g
31
xt is right. See page 366 "The comparison of two
character strings is determined as follows:"
....If the length in characters of X is not equal to the length in ...
string is effectively replaced, for the purposes of comparison, ...
And it really does not make sense you pad a string when you put it
into the table, but don't pad it when you put the same string in
a comparison statment.
Database Management Systme by Raghu Ramakrishnan and Johannes Gehrke
has serveral examples similar to xt's.

【在 x***n 的大作中提到】
: You should read carefully the definition of collation and padding.
: They determine the '=' of strings.
: Oracle adhears to the standard, so are other vendors, and you criticize only
: Oracle for your own fault.
: The same thing happened before, which was why I pointed out.
: Last time, for the posts of "Stupid IBM JDK",
: IBM adhears to the specification, so are other vendors, and you criticized
: only
: IBM for your own mistake.
: I know you still feel IBM sucks (which I don't care), but your starting point

avatar
x*n
32
Eventually got a chance to test Oracle, but forgot to test the so-called
"inconsistency".
Below are my observations:
CREATE TABLE T1 (N CHAR(10)); INSERT INTO T1 VALUES ('ABC');
SELECT LENGTH(N) FROM T1;
MySQL, MS SQL Server: 3 3
Oracle, DB2, Sybase: 10 10
CREATE TABLE T2 (N CHAR(20)); INSERT INTO T2 VALUES ('ABC ');
SELECT COUNT(*) FROM T1, T2 WHERE T1.N = T2.N
ALL: 1
Basically the rationale is here:
Since CHAR dose not have an indicator for the length of this field, (not

【在 xt 的大作中提到】
:
: Don't you think I know this part of the story? Just in case you
: do not understand the situation, or totally are ignorant of Oracle
: JDBC, let me give you an example:
: Create a table with field foo (CHAR32)
: Use JDBC, insert a row with foo="hello"
: Use JDBC, search the table with foo="hello", you get NOTHING back
: Use JDBC, search the table with foo="hello" plus 26 spaces you get
: a row back.
: Use SQL Plus, search the table with foo="hello" you get the record

avatar
xt
33

Try use JDBC with "select count(*) from T1 where N='ABC'". Last time
I used Oracle thin driver (remember, oci driver is not tested and
it is not quite as useful if you want to make sth easier to use),
it was like this. Maybe they ahve fixed sth in last 2 years?
Sir, you are totally clueless.

【在 x***n 的大作中提到】
: Eventually got a chance to test Oracle, but forgot to test the so-called
: "inconsistency".
: Below are my observations:
: CREATE TABLE T1 (N CHAR(10)); INSERT INTO T1 VALUES ('ABC');
: SELECT LENGTH(N) FROM T1;
: MySQL, MS SQL Server: 3 3
: Oracle, DB2, Sybase: 10 10
: CREATE TABLE T2 (N CHAR(20)); INSERT INTO T2 VALUES ('ABC ');
: SELECT COUNT(*) FROM T1, T2 WHERE T1.N = T2.N
: ALL: 1

avatar
x*n
34
i'll have a try next week when i get to work
where i can have access to oracle.

【在 xt 的大作中提到】
:
: Try use JDBC with "select count(*) from T1 where N='ABC'". Last time
: I used Oracle thin driver (remember, oci driver is not tested and
: it is not quite as useful if you want to make sth easier to use),
: it was like this. Maybe they ahve fixed sth in last 2 years?
: Sir, you are totally clueless.

avatar
x*n
35
I didn't see the error in Oracle:
in SQL*Plus:
CREATE TABLE c (n char(32));
SELECT N, LENGTH(n) FROM c WHERE n = 'hello'
N LENGTH(N)
avatar
xt
36

what do you mean by "32" under the WHERE part?
That's what I got back more than 2 years ago:
if you read the string by ResultSet.getString(), you
get "hello"+26 spaces.

【在 x***n 的大作中提到】
: I didn't see the error in Oracle:
: in SQL*Plus:
: CREATE TABLE c (n char(32));
: SELECT N, LENGTH(n) FROM c WHERE n = 'hello'
: N LENGTH(N)

avatar
x*n
37
1. I suppose Oracle store every char(N) as N length,
with padding on, no matter what, so the result you get
back is length N.
2. MySQL and others, sotre every char(N) as N length, (this is obvious),
with padding off when you operate on the content.
e.g. when you INERT INTO c values ('hello'), the data in any RDBMS
is 'hello ... ', which all of us agree.
In operating the content, Oracle pads the data; MySQL and some others
trim the trailing white spaces, so you take back (SELECT *)
1. Or

【在 xt 的大作中提到】
:
: what do you mean by "32" under the WHERE part?
: That's what I got back more than 2 years ago:
: if you read the string by ResultSet.getString(), you
: get "hello"+26 spaces.

avatar
xt
38

This is wrong. It is true they have the padding on in DB, but
it is not correct if you retrieve the data and it still gives
you the padding, because that is not what you originally stored.
Then they have fixed it. Oracle thin client did not do it right before.

【在 x***n 的大作中提到】
: 1. I suppose Oracle store every char(N) as N length,
: with padding on, no matter what, so the result you get
: back is length N.
: 2. MySQL and others, sotre every char(N) as N length, (this is obvious),
: with padding off when you operate on the content.
: e.g. when you INERT INTO c values ('hello'), the data in any RDBMS
: is 'hello ... ', which all of us agree.
: In operating the content, Oracle pads the data; MySQL and some others
: trim the trailing white spaces, so you take back (SELECT *)
: 1. Or

avatar
x*n
39

Like I said long time ago, this is another implemention of the specification
of padding.
You talk about "originally stored" and claim 'hello ' is different
from 'hello'. Actually in CHAR(N), there are only two ways to do:
either padd with white space or trim the trailing spaces. Both change the
original content. This was stated in the specification, and it now just has
the following two situations:
1. Oracle turns padding on;
2. MySQL turns padding off.
I don't have too much exp with versions

【在 xt 的大作中提到】
:
: This is wrong. It is true they have the padding on in DB, but
: it is not correct if you retrieve the data and it still gives
: you the padding, because that is not what you originally stored.
: Then they have fixed it. Oracle thin client did not do it right before.

avatar
xt
40

You have a very interesting understanding of "orginal". If I store
"hello" into DB, how could the original be "hello" plus padding?
Orginal as of the DB? Please have some common sense.
Try Oracle 8.

【在 x***n 的大作中提到】
:
: Like I said long time ago, this is another implemention of the specification
: of padding.
: You talk about "originally stored" and claim 'hello ' is different
: from 'hello'. Actually in CHAR(N), there are only two ways to do:
: either padd with white space or trim the trailing spaces. Both change the
: original content. This was stated in the specification, and it now just has
: the following two situations:
: 1. Oracle turns padding on;
: 2. MySQL turns padding off.

avatar
x*n
41

How about I store 'hello ... '?
Like I said, they are just 2 implementations of the same spec
I told you I don't have the version(s).

【在 xt 的大作中提到】
:
: You have a very interesting understanding of "orginal". If I store
: "hello" into DB, how could the original be "hello" plus padding?
: Orginal as of the DB? Please have some common sense.
: Try Oracle 8.

avatar
xt
42

If you store "hello...." into it, you are asking for trouble
by the specification, because it becomes ambiguous. It might be
sensible based on the specification to have the white spaces
returned, but it is absolutely ridiculous because it is not the
common sense. I am talking about the quality of the software.
A good software should be easy to use. You don't want every DB
user to go over those standard mumbo-jumbo in such details. Simply
put, I store sth in, and I want the same thing back. Tell

【在 x***n 的大作中提到】
:
: How about I store 'hello ... '?
: Like I said, they are just 2 implementations of the same spec
: I told you I don't have the version(s).

avatar
x*n
43
We don't sotre 'hello ' manually, but normally the system takes input
not by hand, but throught some forms and other stuff, where people can
easily type in some trailing spaces, or when they copy the content from
a file, and paste it into the forms, even \r\n might be there.
All that I said, was to say Oracle is just doing another implementation.

【在 xt 的大作中提到】
:
: If you store "hello...." into it, you are asking for trouble
: by the specification, because it becomes ambiguous. It might be
: sensible based on the specification to have the white spaces
: returned, but it is absolutely ridiculous because it is not the
: common sense. I am talking about the quality of the software.
: A good software should be easy to use. You don't want every DB
: user to go over those standard mumbo-jumbo in such details. Simply
: put, I store sth in, and I want the same thing back. Tell

avatar
x*n
44
The problem is from the ambiguicity of the spec.

【在 xt 的大作中提到】
:
: If you store "hello...." into it, you are asking for trouble
: by the specification, because it becomes ambiguous. It might be
: sensible based on the specification to have the white spaces
: returned, but it is absolutely ridiculous because it is not the
: common sense. I am talking about the quality of the software.
: A good software should be easy to use. You don't want every DB
: user to go over those standard mumbo-jumbo in such details. Simply
: put, I store sth in, and I want the same thing back. Tell

avatar
xt
45

The problem is not from the spec. It is from the
understanding of behaviours. The spec clearly says
that if the input is too short, it will pad with
spaces. This implies that spaces are trivial input
that is not considered as real data, because padding
is not part of data. It is just used to justfy the
format of data. From this point of view, the stripping
of padding should be transparent to user.
The problem rises when the user inputs data with padding
characters. In this case the user is aski

【在 x***n 的大作中提到】
: The problem is from the ambiguicity of the spec.
相关阅读
logo
联系我们隐私协议©2024 redian.news
Redian新闻
Redian.news刊载任何文章,不代表同意其说法或描述,仅为提供更多信息,也不构成任何建议。文章信息的合法性及真实性由其作者负责,与Redian.news及其运营公司无关。欢迎投稿,如发现稿件侵权,或作者不愿在本网发表文章,请版权拥有者通知本网处理。