Hi!
Well, I guess that depends mostly on your resources usage and
availability. But for 200 MB I would not move a finger. :)
Anyway, check Frontbase docs for more info about vacuuming, I don't
even know if they have that concept. If they do, check if it's
possible to automate it. Post
Hi Jeff,
You may want to take a look at the "optimize database" command for
Frontbase as well. See page 115 of the users guide.
David
On 17-Mar-09, at 9:29 AM, Jeff Schmitz wrote:
Thanks Miguel,
Very informative. I'm using Frontbase. I cleaned out a lot of
unneeded rows in several
Thanks Miguel,
Very informative. I'm using Frontbase. I cleaned out a lot of unneeded
rows in several tables in hopes that it would speed by pre-fetching. Sounds
like most of the extra info produced by this will remain on the disc. Is there
a size of the database where you may want to "va
Hi!
Jeff, this depends on the DB engine you are using.
On Postgresql, you have two sets of files. The base files, which
contains the "stable" data, and the write-ahead logs (WALs). Every
time you do an operation, whatever that is (including delete), the
operation is written to the WALs
Hi Jeff,
I suppose it depends upon the database, but it's possible the backup
is also backing up the transaction logs. In which case until they are
truncated your backup will never get smaller, only bigger.
Dave
On Mar 17, 2009, at 5:02 AM, Jeff Schmitz wrote:
This may be a dumb question,
This may be a dumb question, but why after deleting a bunch of EOs is
my database backup larger than before? Looking at the data in the
database, the data corresponding to the EOs does seem to be gone now.
Jeff
___
Do not post admin requests to the
