FWIW :

this is the same behaviour as Oracle (!), CHAR fields get padded with spaces
and VARCHARs don't.
If a field is CHAR(5) and you store 'A' in it, it will be stored as 'A '
and a test for 'A' will fail.

I think SQLServer (double !) does this as well.

VARCHARs only store as much data as you tell it to, so the 'A' is stored as
'A' and a test for 'A' will work as expected.

Confuses the hell out of some of our developers here - until the know about
the difference that is :o)


Regards,
Norman.

----------------------------------------------------------------------------
-
Norman Dunbar EMail: Norman.Dunbar@...
Database/Unix administrator Phone: 0113 289 6265
Fax: 0113 289 3146
Lynx Financial Systems Ltd. URL: http://www.Lynx-FS.com
----------------------------------------------------------------------------
-


-----Original Message-----
From: Helen Borrie [mailto:helebor@...]
Sent: Thursday, September 27, 2001 9:11 AM
To: IBObjects@yahoogroups.com
Subject: Re: [IBO] Re: Sending demo of Problem


At 10:09 AM 27-09-01 +0200, you wrote:

>Helen,
>
> > 2. I set your Keylinks to ID. (Notice that I had a little trouble with

this because you made this a char(12) so your unique id values get stored as
"FIRST ", "SECOND " and "THIRD " and a query 'where "ID" =
'FIRST' will not find the row...

>
>According to the SQL standard and how IB implements it, it surely
>should.

Nando,
Test it for yourself. Char fields get right-padded with ascii 32 at
creation time.

Helen