--- In IBObjects@y..., Daniel Rail <daniel@a...> wrote:

>cant re-find it. Was it 24 chars ??
>
> For blobs, there's only a blob id that is stored and points to the

blob

> itself when one is needed for the field. If I'm not mistaken the

blob id

> is a 64bit integer. So, if no blob is defined for the record, then

the

> only space taken up is 64bits. The only downside to using blobs is

that

> they are not searchable just using a SELECT statement, you might

have to

> implement your own search methods or use a full text search engine

as the

> one that Jason has. By giving a blob to your customer, you wont be

bugged

> anymore to increase the comment field size.
>
> On the other hand, increasing the field from varchar(40) to varchar

(100)

> isn't much of a deal. As mentioned before, the size stored in the

database

> is the same concept, but you will be transferring 100 characters

instead of

> 40 characters to your application.
>
> >To this has to be added programming complexity but if I have to

then

> >I will.
>
> To know what needs to be changed, if required is up to you. Since

you know

> the code better than any of us. Definitely, if switching over to a

blob,

> you might need to use a memo component to enter and view the text.
>
>
> Daniel Rail
> Senior System Engineer

Thanks for your help. Have I been worrying my poor old head about
wasting space for all this time? Why not have a varchar(255) if it
really takes no space in the database when null?
Yes I expect to use memo components to put such comments in.
I suppose I could do some experiment to test the fact that null
columns occupy no space but I have not seen that in the Interbase
manuals anywhere...perhaps I should know it anyway. I have always
been confused about varchar(20) versus char(20).
Any confirmation would be welcome.
Dave