At 06:59 PM 15/02/2006, you wrote:

>Helen,
>
> > >If I have strings like that and i want to insert it into the
> > >databsae how do i solve this problem.
> >
> > Well, define the fields as char to *store* the trailing white space
> > characters (making 'abc', 'abc ' and 'abc ' three distinct values)
> > but nothing is going to help you to get past the equivalence test
> > rules. It is just not at all a bright idea to allow trailing white
> > space to be meaningful.
>
>Is it me, or this this wrong?

No, it's me. :-(

>Won't a CHAR -always- return the value with padded spaces?
>That is, 'abc' will be returned as 'abc___' (where "_" means a
>padded space) if the column is defined as CHAR(6) and 'abc '
>will be returned as 'abc __'?

Yuk, yes, sorry...

create table words (
wordid integer not null,
cword char(252),
vword varchar(252),
constraint pk_word primary key(wordid));
commit;

create unique index u_cword on words(cword);
create unique index u_vword on words(vword);
commit;

SQL> insert into words values (1, 'abc', 'abc');
SQL> insert into words values (2, 'abc ', 'abc ');
Statement failed, SQLCODE = -803

attempt to store duplicate value (visible to active transactions) in
unique index "U_CWORD"
SQL> insert into words values (2, 'ab c', 'abc ');
Statement failed, SQLCODE = -803

attempt to store duplicate value (visible to active transactions) in
unique index "U_VWORD"
SQL>

So the trailing blanks are lost either way [ and a highly persuasive
reason not to define a char(252), besides being a highly persuasive
reason not to accept a design requirement to store trailing blanks :-) ]

./heLen