By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
425,863 Members | 879 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 425,863 IT Pros & Developers. It's quick & easy.

Front end larger than back end in Access 97

P: n/a
I manually split my database - in a blank database, I copied all the
forms, reports, etc. and linked to the tables in my original database.
The front end has grown to 12,818kb and the back end, where my tables
are, is only 6,472kb. How can this be? Does the front end need to be
compressed? I thought if the data is actually being stored somewhere
else, it wouldn't need to be compressed. Any ideas?

Thanks in advance,
JD
Nov 12 '05 #1
Share this Question
Share on Google+
4 Replies


P: n/a
Tried compacting at least once?

<jd****@yahoo.com> wrote in message
news:75**************************@posting.google.c om...
I manually split my database - in a blank database, I copied all the
forms, reports, etc. and linked to the tables in my original database.
The front end has grown to 12,818kb and the back end, where my tables
are, is only 6,472kb. How can this be? Does the front end need to be
compressed? I thought if the data is actually being stored somewhere
else, it wouldn't need to be compressed. Any ideas?

Thanks in advance,
JD

Nov 12 '05 #2

P: n/a
jd****@yahoo.com (jd****@yahoo.com) wrote:
I manually split my database - in a blank database, I copied all the
forms, reports, etc. and linked to the tables in my original database.
The front end has grown to 12,818kb and the back end, where my tables
are, is only 6,472kb. How can this be? Does the front end need to be
compressed? I thought if the data is actually being stored somewhere
else, it wouldn't need to be compressed. Any ideas?


As Mark posted try compacting.

But if you are also usinga lot of graphics on forms and reports, such as backgrounds
or logos this could easily bloat the FE by a Mb per graphic.

Tony
--
Tony Toews, Microsoft Access MVP
Please respond only in the newsgroups so that others can
read the entire thread of messages.
Microsoft Access Links, Hints, Tips & Accounting Systems at
http://www.granite.ab.ca/accsmstr.htm
Nov 12 '05 #3

P: n/a
If you are creating and using temporary tables, that space will not be
recovered until you Compact. An alternative to avoid bloat from temporary
tables can be found at MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm -- an example of creating a temporary
database in which you create the temporary tables and when you are done with
them, you just use the Kill statement to delete the whole temporary
database.

There are also some queries that create/use temporary workspace internal to
Access (we don't see and can't access it), but that, too, must be recovered
by Compact.

That is why both Mark and Tony suggested periodically running Compact.

Larry Linson
Microsoft Access MVP

<jd****@yahoo.com> wrote in message
news:75**************************@posting.google.c om...
I manually split my database - in a blank database, I copied all the
forms, reports, etc. and linked to the tables in my original database.
The front end has grown to 12,818kb and the back end, where my tables
are, is only 6,472kb. How can this be? Does the front end need to be
compressed? I thought if the data is actually being stored somewhere
else, it wouldn't need to be compressed. Any ideas?

Thanks in advance,
JD

Nov 12 '05 #4

P: n/a
Thank you for the replies. I ran Compact this morning and the
strangest thing happened. When I tried the shortcut on my desktop, I
got this message: Unrecognized database format. I looked in Windows
Explorer and the name of the database had been changed from Safety
Incidents.mdb to Safety IncidentsIO.mdb. I had put a copy of the
database on my hard drive, so I just copied it back. Any ideas what
could have caused this to happen? I've run Compact before on other
databases without any problems.

Thanks,
JD

"Larry Linson" <bo*****@localhost.net> wrote in message news:<iA****************@nwrddc01.gnilink.net>...
If you are creating and using temporary tables, that space will not be
recovered until you Compact. An alternative to avoid bloat from temporary
tables can be found at MVP Tony Toews' site,
http://www.granite.ab.ca/accsmstr.htm -- an example of creating a temporary
database in which you create the temporary tables and when you are done with
them, you just use the Kill statement to delete the whole temporary
database.

There are also some queries that create/use temporary workspace internal to
Access (we don't see and can't access it), but that, too, must be recovered
by Compact.

That is why both Mark and Tony suggested periodically running Compact.

Larry Linson
Microsoft Access MVP

Nov 12 '05 #5

This discussion thread is closed

Replies have been disabled for this discussion.