At 15/03/2002 02:45 PM, you wrote:

>I have avoided using 'blobs' because of added complexity. I have a
>table with a column 'comments varchar(40)'. Now my client wants this
>increaed to varchar(100). Only one in 20 records gets any comment
>added, so there is a lot of space characters about !
>It seems this is a case for a blob memo ...but what is the 'overhead'
>of a blob ? I am sure I read this somewhere but I have searched and
>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
ACCRA Group Inc. (www.accra.ca)
ACCRA Med Software Inc. (www.accramed.ca)