File grows rapidly

[Rajesh Candamourty]

Dear ALL,

I have an access database designed in multiuser environment. I have used
Active X controls in my forms. I have 72 users in this application.

Right now i have a front end of file size 50Mb and backend of file size
15Mb.

All the 72 users have the front end installed in their system, and anything
they input and hit save, logically my backend alone has to grow in its size.
but my front end also grows. The growth is fast atleast 300-400 Kb per
saving. And i have no idea whats going on here.

Am i doing something wrong here?

Help me.

Any help is highy appreciated.

Thank you.
Raj.

 

[Joseph Meehan]

Dear ALL,

I have an access database designed in multiuser environment. I have
used Active X controls in my forms. I have 72 users in this
application.

Right now i have a front end of file size 50Mb and backend of file
size 15Mb.

All the 72 users have the front end installed in their system, and
anything they input and hit save, logically my backend alone has to
grow in its size. but my front end also grows. The growth is fast
atleast 300-400 Kb per saving. And i have no idea whats going on here.

Am i doing something wrong here?

Help me.

Any help is highy appreciated.

Thank you.
Raj.

I am not sure what might be going on, but are there any tables in the
front ends?

Have you compacted both front and back ends?

 

[Guest]

Set both the Front End and Back End databases to compact on close. The
growth you are seeing is sorta normal, but a little faster than usual. My
guess would be it is a design issue. If you do a lot of importing and
deleting, using temporary tables, etc. this can happen.

 

[Rajesh Candamourty]

i do have tables in the front end but they are linked to the backend

 

[Rajesh Candamourty]

am not using any temporary tables or any deleting or importing

 

[Rajesh Candamourty]

is compacting advisable...?

Set both the Front End and Back End databases to compact on close. The
growth you are seeing is sorta normal, but a little faster than usual. My
guess would be it is a design issue. If you do a lot of importing and
deleting, using temporary tables, etc. this can happen.

 

[Guest]

Yes, it is. It keeps the file size down and can help avoid corruption.

 

[Marshall Barton]

I have an access database designed in multiuser environment. I have used
Active X controls in my forms. I have 72 users in this application.

Right now i have a front end of file size 50Mb and backend of file size
15Mb.

All the 72 users have the front end installed in their system, and anything
they input and hit save, logically my backend alone has to grow in its size.
but my front end also grows. The growth is fast atleast 300-400 Kb per
saving. And i have no idea whats going on here.

Check carefully that you are not creating/saving any
objects, especially a form or report. Sometimes, these this
can be subtle, for example I have seen people use
DoCmd.RunCommand acCmdSave thinking it would save a record,
when it actually saves the form's design.

Of lesser impact, but still a possible bloat cause is
creating or modifying QueryDef objects.

Another possible reason is that you project is somehow
becoming decompiled everytime you open it. As the
application runs it would then have to compile any code the
is executed. Changing a reference in some startup code
would be one reason for this to happen.

 

[Rajesh Candamourty]

if u can give a reson on the design issue, i would try to look it up to
change some code.

 

[Guest]

I think Marshall Barton covered it pretty well. One other thing to consider,
is if you are import external data like Excel spreadsheets regularly,
consider linking instead of importing.

 

[Marshall Barton]

I hate to get into another argument, but I don't like to
trust a heavy duty operation such a compact to work
flawlessly every time. (Note that Compact rewrites every
byte in the file.)

Recovering from a front end compact failure is usually just
a matter of reinstalling the file. Regardless, a bloating
front end is indicative of a less than optimal design and/or
code and that should be at least understood, if not fixed.
Hiding it behind frequent Compacts is IMO just a cop out.

OTOH, a back end compact failure might be catastrophic if
you don't make very frequent backups. Note that for many
kinds of corruption that may have crept into your data, a
Compact can easily make it much worse.

For all these reasons, I recommend that Compact only be done
as part of a database administration procedure that includes
a robust backup operation.

 

[Rajesh Candamourty]

thank you for ur inputs guys.
I appreciate ur help.