Home | Contact Us | FAQ | Search & Site Map | Link to Us
Sign In | Join | Other 45 Sites in Network
Home
Discussion GroupsFormsForms ProgrammingQueriesModules / DAO / VBAReports / PrintingMacrosDatabase DesignSecurityConversionImporting / LinkingSQL Server / ADPMultiuser / NetworkingReplicationSetup / ConfigurationDeveloper ToolkitsActiveX ControlsNew UsersGeneral 1General 2
Access DirectoryToolsTutorialsUser Groups
Related Topics
SQL ServerOther DB ProductsMS OfficeMore Topics ...

MS Access Forum / General 1 / December 2005

Tip: Looking for answers? Try searching our database.

Database doubles in size, when forms deleted even when compacted!

Thread view: 
Enable EMail Alerts  Start New Thread
Thread rating: 
Jozef - 11 Dec 2005 03:55 GMT
Here's a strange one.  I made a modification to a database recently, and
wound up getting an error message when trying to make an mde file.  I'm
using Access XP/2002, and the error message I got was "Microsoft Access was
unable to create an mde database".  After researching the error and the
solutions, I've run the gamut of solutions (or comply with the requirements)
when I came across the "maximum table ids" issue which can cause this error.

Although the database is quite large, I can't really see that being an issue
since I just made an mde out of the database a few days ago.  The FE
database seems a little larger than usual (about double the size it normally
is from around 40mb to 96mb), but I didn't think too much of it.    To test
it, I deleted about 1/2 the forms in the database, and compiled it.  The
database doubled in size again to about 186mb.  I figured o.k. when I
compact it, it will likely go back to a reasonable size, but it didn't.
EVEN COMPACTED with HALF the forms, the database is STILL 186mb!

I've rebooted, I'm using the latest service pack, it's running on a Windows
XP machine with the latest service pack.  On top of all that, I still can't
create an MDE file!

Any ideas?  I'm all out!

Thanks!
Jozef - 11 Dec 2005 03:57 GMT
I should also mention that I did create a new database and imported all
objects into it, compiled and compacted it, and it's STILL producing the
same problems, including it's immense size.
Jozef - 11 Dec 2005 06:26 GMT
Still not sure what happened, but here's how I got around it.

I converted the db from XP/2002 to a 2000db, then I converted it back to an
XP/2002 db.  reduced the size from 186 to36mb.

>I should also mention that I did create a new database and imported all
>objects into it, compiled and compacted it, and it's STILL producing the
>same problems, including it's immense size.
BillCo - 12 Dec 2005 09:02 GMT
I had a similar problem to this years ago when I was starting out. The
more I tried to reduce the size of the database by creating fresh front
ends and importing objects the worse it got. Compacting, decompiling
etc. didn't work. Then I realised that when I was importing the tables
to my fresh database, I was also importing the system tables. They were
being named MSysObjects_1, and_2 etc. The database grew exponentially
in size very quickly and I had a front end that should have been 25mb
up at 135mb.

If this was the same problem, I'm not sure how converting to a2k and
back could have sorted it for you - but it's just a thought.
Larry Linson - 11 Dec 2005 06:32 GMT
>I should also mention that I did create a new database and imported all
> objects into it, compiled and compacted it, and it's STILL producing the
> same problems, including it's immense size.

For one thing, you should have split your database into a front-end (tables,
data, and relationships) and a back-end (queries, forms, reports, macros,
and modules). You link to the tables in the back-end from the front-end.
Only the front end need be compiled to MDE, but both the front and back ends
may have to be compacted.

There's a menu entry for the Splitting Wizard, or, you could simply make two
copies of your database, eliminate from each copy those things that you
don't need. Then find an appropriate folder in which to store the back end -
shared by all users.

 Larry Linson
 Microsoft Access MVP
Wayne Gillespie - 11 Dec 2005 06:48 GMT
> >I should also mention that I did create a new database and imported all
> > objects into it, compiled and compacted it, and it's STILL producing the
[quoted text clipped - 13 lines]
>  Larry Linson
>  Microsoft Access MVP

>The FE database seems a little larger than usual
I think this would suggest that he has split the database Larry.

Wayne Gillespie
Gosford NSW Australia
Jozef - 11 Dec 2005 13:56 GMT
Yes, the database is split, and I was only referring to the FE or the Front
End.

>> >I should also mention that I did create a new database and imported all
>> > objects into it, compiled and compacted it, and it's STILL producing
[quoted text clipped - 24 lines]
> Wayne Gillespie
> Gosford NSW Australia
Lyle Fairfield - 11 Dec 2005 14:23 GMT
You couldn't imagine a 96 megabyte front end , Larry? Me neither.

I try to keep my front ends small enough to fit on a 3.5 floppy.
BillCo - 12 Dec 2005 09:04 GMT
>I try to keep my front ends small enough to fit on a 3.5 floppy.

Lyle, that's interresting - I have a front end hovering around 20mbs
after compact...
But it is pretty big - 600 queries, 160 linked tables, 80 local tmp
tables (always emptied  after use), 140 forms, 260 reports, 120 modules
and a handful of *ahem* macros.

It was double that before I took over it and cleared out the
non-essential crap.
If you could give any pointers on how to bounce this down to floppy
size I would be eternally in your debt!
Lyle Fairfield - 12 Dec 2005 11:52 GMT
I'll just content myself with admiring you for clearing out the
non-essential crap and shut up, Bill.
BillCo - 12 Dec 2005 14:53 GMT
Sorry, I've just re-read my post and it sounds like I'm being a smart
arse - but I'd genuinely like to try to strip down the size... but
short of a complete re-design I'm out of ideas. sadly i think that's
because there are no more tricks :(
Lyle Fairfield - 12 Dec 2005 15:50 GMT
Bill
I didn't think you were being a smart arse.

I did not want to get into a discussion of big front ends; this would
lead to a discussion of
- temp tables (I never use any);
- msde (where queries live in the backend) -> which would lead to a
discussion of ADPs and ODBC and maybe even ADO;
- Access as a suitable vehicle for a BIG application such as you
describe.

We've had many discussions here in CDMA about these things. Many
regulars don't agree with me about them. The discussions go on and on
and sometimes get nasty. I don't see any point in going there again.

I think you are a new poster to CDMA (I haven't noticed you before).
Your post seemed intelligent. We don't get so many of these anymore. I
wanted to encourage you to stay, not to go.

I know of only a few ways to keep the size of the FE in check:

a) no images on forms;
b) prevent temporary (JET created without asking) queries;
c) no temp tables; use ADO recordset save and open to text files if
necessary, but try to make it not necessary);
d) frequent savingastext all objects and reloadingastext to get rid of
the crud (during development);
e) having an efficient coding and object designing style;
f) don't use wizards.

I'm not saying that any of these is the right thing to do; I'm saying
they are the things I try to do.
BillCo - 12 Dec 2005 16:21 GMT
Thanks Lyle,

I'm afraid it looks like a complete re-design then for my inherited
bloatware... which is not going to happen this side of an upgrade to
.net vs sql server (a prospect which both terrifies me to my core and
is pretty exciting)

>b) prevent temporary (JET created without asking) queries;

...interesting - I'll look into that
 
Sign In
Join
My Latest Posts
My Monitored Threads
My Blog
My Photo Gallery
My Profile
My Homepage

Start New Thread
Enable EMail Alerts
Rate this Thread



©2008 Advenet LLC   Privacy Policy - Terms of Use
This website includes both content owned or controlled by Advenet as well as content owned or controlled by third parties.