Subject Re: why you can't compress a database file?
Author Adam
--- In, "Nigel Weeks" <nweeks@...>
> >
> > The "compress" word lead me to think about zip or something

> 'Compact' might be a better word, implying filling in the empty
space, and
> shortening the DB.
> N

Another great article Ann.

I agree with Alexandre and Nigel. I was half expecting (from the
title) to read about file system locks and the fact that the TIP
would say a transaction is active but by the time it gets to the data
page it may have committed causing interesting fireworks, a technical
explanation of why one can't simply xcopy or winzip a database (that
is in use).

I imagine this page shuffling would be similar conceptually to any
defragmentation process, the added burdon of maintaining the various
index links. It is clearly a lot more complex to maintain than a
FAT32 structure.

Perhaps a paragraph getting them to think about the consequences of
compacting the database? If your process is of the type that fills a
temporary table then deletes it when the process is complete, then
(to me anyway) it would be a waste of time to compact your database.
There would be significant resource overhead while it occurred and
the benefits would be lost as soon as your next process started.

The only time that I see it as a 'nice to have' would be if you had
some end of year process that see huge growth in database size.