Compact and Repair

I have database that is stored on a shared network drive, its size is 685mb,
to Compact and Repair I copy the database to my desktop, Compact and Repair
and get it down to 73mb, I then copy it back to the network drive. The
problem is that in 5 to 10 mins. it goes back to 685mb. Any ideas or
sugesstions? Thanks.

why can't you compact and repair it on the drive? my thing is that it's
probably the same database on the network drive .. unless you're
deleting it from the network drive. and then replacing it with the new
compacted version. first backup the database then compact and compres
it.
hth

The problem I have is getting everyone to close the database, there's alway
someone that has opened or minimized on their desktop, that why I can't
compact and repair on the network drive, so after I compact and repair on my
desktop I copy and replace the database on the network drive.

" wrote:

why can't you compact and repair it on the drive? my thing is that it's
probably the same database on the network drive .. unless you're
deleting it from the network drive. and then replacing it with the new
compacted version. first backup the database then compact and compres
it.
hth

It balloons up 10x in just a few minutes? Something is really wrong there.

1. Are you sure that you aren't comparing apples to oranges? That one
computer is showing MB while the other is showing KB? Probably not as this
should show 1000x more. Still do a right click on the file in Explorer and
see what the properties say.

2. Are you doing a lot of Make Table queries then deleting records or
dropping tables? Something like temporary work tables? Are you importing in a
lot of data? How about bunches of Union queries or queries with sorting and
grouping?

3. Is the database split between a Front End (FE) with forms, reports, code,
etc. and a Back End (BE) with just the tables? If not consider doing so ASAP.

If you search on access database bloat, you will find a lot of information.


--
Jerry Whittle
Light. Strong. Cheap. Pick two. Keith Bontrager - Bicycle Builder.


"Dryder" wrote:

I have database that is stored on a shared network drive, its size is 685mb,
to Compact and Repair I copy the database to my desktop, Compact and Repair
and get it down to 73mb, I then copy it back to the network drive. The
problem is that in 5 to 10 mins. it goes back to 685mb. Any ideas or
sugesstions? Thanks.

In my opinion, it is a BAD idea to do this with an open database. If
someone has the database open they could be posting changes to it and you
will either lose their changes or may end up with a corrupt copy of the
database.

You can see if the database is open by looking for the lock file (name of
database.ldb) in the same folder as the data.

There are ways to have the users shut down. One - threats of violent
action. Two - check the newsgroups for ways to code your database to force
the users' copies to shut down after a specified interval.


"Dryder" wrote in message
...
The problem I have is getting everyone to close the database, there's
alway
someone that has opened or minimized on their desktop, that why I can't
compact and repair on the network drive, so after I compact and repair on
my
desktop I copy and replace the database on the network drive.

" wrote:

why can't you compact and repair it on the drive? my thing is that it's
probably the same database on the network drive .. unless you're
deleting it from the network drive. and then replacing it with the new
compacted version. first backup the database then compact and compres
it.
hth

Why not set the "compact on close" option in Tools-Options-General. This
way, whenever someone uses it and closes the database, the Compact function
is automatically run. Just a thought

"Dryder" wrote:

I have database that is stored on a shared network drive, its size is 685mb,
to Compact and Repair I copy the database to my desktop, Compact and Repair
and get it down to 73mb, I then copy it back to the network drive. The
problem is that in 5 to 10 mins. it goes back to 685mb. Any ideas or
sugesstions? Thanks.