I know that the "best practice" is to initialize everything
however...

I'm adding a memo field to an existing large table.
Can I safely assume that I don't need to step through the whole
table initializing the new memo field?

I should know this (& probably do somewhere in the cobwebs
of my mind )

Jon

"Jon Lloyd Duerdoth" <jld@welshdragoncomputing.ca> wrote in message
news:137C0164-8A74-43AD-9075-951BC3E0BDD7@news.elevatesoft.com...
>I know that the "best practice" is to initialize everything
> however...
>
> I'm adding a memo field to an existing large table.
> Can I safely assume that I don't need to step through the whole
> table initializing the new memo field?

The best way is, when you create the field, assign a default. Let DBISAM
take care of initializing the field.

alter table mytable add tablememo memo default ''

I think if you don't initialize a memo it behaves just as if you initialize
it to an empty string, but as a matter of good practice, unless the NULL
value means something to your application, I initialize every field with a
default.

Robert

Robert


Since DBISAM operates the highly sensible NULL is the same as Emptyspace there is no point in initialising either varchar or memo fields to emptyspace.

I don't know if its the same in DBISAM, and Tim may have altered the behaviour in ElevateDB but when I tested that in ElevateDB it allocated the BLOBBLOCKSIZE to every record. In a large table this can make an appreciable difference in file size.

Roy Lambert

"Roy Lambert" <roy.lambert@skynet.co.uk> wrote in message
news:7BD69C3A-2D21-4AE4-8873-733619AD32B0@news.elevatesoft.com...
> Robert
>
>
> Since DBISAM operates the highly sensible NULL is the same as Emptyspace
> there is no point in initialising either varchar or memo fields to
> emptyspace.
>

As long as / Field.Value = '' / returns true when the field is NULL (both in
Pascal and in SQL), then you're right, there is no need to initialize it.

> I don't know if its the same in DBISAM, and Tim may have altered the
> behaviour in ElevateDB but when I tested that in ElevateDB it allocated
> the BLOBBLOCKSIZE to every record. In a large table this can make an
> appreciable difference in file size.
>

I assume you meant "I tested that in DBISAM". Correct?

Robert

Robert

>I assume you meant "I tested that in DBISAM". Correct?

I meant what I wrote

Roy Lambert [Team Elevate]

Roy,

<< I don't know if its the same in DBISAM, and Tim may have altered the
behaviour in ElevateDB but when I tested that in ElevateDB it allocated the
BLOBBLOCKSIZE to every record. In a large table this can make an appreciable
difference in file size. >>

1) This is changed in ElevateDB 2.01 B2:

http://www.elevatesoft.com/incident?action=viewrep&category=edb&release=2.01&type=f&incident=2705

2) DBISAM does not allocate space when the size of a BLOB is 0.

--
Tim Young
Elevate Software
www.elevatesoft.com

Tim


I hadn't tested it again (or ever tested DBISAM) which is why I put the caveats in.

Roy Lambert