SHARED DB EXPANDS TO 2 GIG

R

RAN

I have a shared database that after being compressed is less than 50 mb.
During the day as about 8 to 10 people are accessing through a front-end
process, the shared DB grows to 2GB and then needs to be re-compressed. Any
suggestions on how to prevent this from happening or at least slow it down so
it would only have to be compressed after day-end?
 
P

pietlinden

I have a shared database that after being compressed is less than 50 mb.
During the day as about 8 to 10 people are accessing through a front-end
process, the shared DB grows to 2GB and then needs to be re-compressed. Any
suggestions on how to prevent this from happening or at least slow it down so
it would only have to be compressed after day-end?

not enough info to go on.... what are the users doing in the
database? Creating temporary tables? (That could do it....)
 
D

Dale Fye

1. Is this application split into individual front-end applications, all
linked to a single back-end? If not, you need to do so.

2. If so, are you creating temporary tables in the backend? If so, look at
Tony Toew's web site for some ideas about creating temp tables in a
temporary database. (http://www.granite.ab.ca/access/temptables.htm)

HTH
Dale
 
K

KARL DEWEY

I assume you have Access 2007.
Click on the Office button, select Access Option in the lower right of
window, and click on Current Database.
The third check box down says 'Compact on Close.' Check the box.
Instruct all user to close the database when they are not actually using it.
 
R

RAN

We're using Access 2003. The problem is with the backend shared database
growing to the 2GB limit. The front-end users then get the error message
"Invalid Argument".
 
R

RAN

We're adding and editing records in two tables using a couple forms. I don't
know if Access is creating temporary tables?
 
R

RAN

1. Yes. There is a front-end application consisting of a couple forms, which
add and edit records in a couple tables in the shared back-end.
2. I don't know if Access is creating temporary tables in the back-end. How
can I tell?
 
D

Dale Fye

Access won't create "temporary" tables on its own. The developer is
responsible for these, if they exist. Generally, when you have this type of
bloat and shrinkage all occurring within a single day, it is likely that it
is because your users are inserting and deleteing lots (I mean LOTS) of
records into a "temporary" table, and then deleting those records. This is
common in many databases where the developer felt they needed to move data
to a "temporary" table before generating a report, or before massaging that
data to present it in a report.

Unfortunately, there is no "easy" way to detect which tables are being used
for this purpose, other than reviewing the code.
The first thing I would do is look through all of your saved queries
(specifically look for Maketable, Delete, and Append queries). These will
give you an indication as to which table are being written to and deleted
from (causing the bloat and shrink phenomonon you are encountering).

Next, you might want to search the VB code window for the term "INSERT" or
"DELETE" in relation to SQL strings that are being written dynamically, and
which are writing/deleteing large numbers of records from one or more
tables.

Once you identify the tables that are causing your bloat, then you may be
able to remove them from the backend, and put them in a temporary database
that is local to each user (see my reference to Tony's website below).

HTH
Dale
 
R

RAN

Thank you. I've isolated the bloat to a single table to which new records are
being appended to several times a day. Then four queries run that update
certain fields from other master tables. I've moved this table to reside in a
stand alone shared db file. This has slowed down the bloat in the total
process, but I'm still going to have to work on compensating for this. Thanks
again.
 
A

a a r o n . k e m p f

if your database bloats too much-- then maybe you should move to SQL
Server

this sort of stuff isnt' an issue with SQL Server
 
A

a a r o n . k e m p f

what you mean to say-- is that Access doesn't support the concept of
'temporary tables'

if you want to focus on development-- and not worry about crap like
this-- then just move to SQL Server
 

Ask a Question

Want to reply to this thread or ask your own question?

You'll need to choose a username for the site, which only take a couple of moments. After that, you can post your question and our members will help you out.

Ask a Question

Top