Time to move on...

RoyVidar wrote:
(PeteCresswell) wrote in message
:
Per PeterM:
There is our company logo on
each of them and I'm hoping that will reduce the size.

Been there. Can't remember the numbers, but it was amazing how
much memory the graphics eat up on MS Access reports.

Would it help to use one small report for the logo, the use that as
subreport on all the others?

Yes. Then you are only embedding the image once. I once trimmed 15MB doing
exactly that.

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

This is fascinating...

If I understand you correctly...I can take my existing .mdb (80meg) and
break it into smaller .mdb's and then create a master .mdb that calls the
forms in one of the smaller .mdb's.

In order to do this, I need to add a reference to all of the smaller .mdb's
in the master .mdb (Tools References). do I have it correct?

Is there some documentation or an example that you know of I could see?

Thanks David!

"david epsom dot com dot au" wrote:

Our application is about that big (80). Zipped, it is about
12 meg. Compressed to self extracting executable with rar,
then zipped, it is about 10.

The application has a shell mdb/mde, 4-12 application
mde's at 1-10MB, and a library mde at 10MB.

Each application module references the library mde
(tools, references).

The shell references all of the application modules
and the library module.

For ease of installation and support, we require all
clients to install to the specified program files
folder.

When using the shell as an mdb, we can replace any
application mde, provided the library mde does not
change.

If you use application mdb modules, then you could
also update the library module without changing all
application modules.

Or you might not have enough shared code to justify
a library module.

We also have code in DLL's: these may be updated
independently of the mde's.

Within the application modules, some forms call other
forms. From the shell, application modules are called
from the menu system.

(david)


"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options. I
have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg. It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or
find
something that will convert the Acess app to another language such as VB
.NET
or JAVA where we can have a thin client or where I can break the form in
the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have. Thank
you
in advance for your advice!

You can't directly call a form (it was never easy, and
the feature was disabled in A2003). Instead, you need
to have a function in each module to open forms and
run reports. And nothing appears in the database window
of the shell - you need to add items to a custom menu
to call your application entry points.

In order to do this, I need to add a reference to all of the
smaller .mdb's in the master .mdb (Tools References).
do I have it correct?

Yes.

Is there some documentation or an example that you know of I could see?

Not that I can think of. Access version 2.0 was built like
this, so you could see all of the wizards and utilities as
examples, and even in A97 some of the wizards and utilities
were built sort of like this, but not any more.

BTW, when you have all your mdb's loaded, you can also call
down and sideways from one to another, using Run or Eval.
Code can call up directly.

DLookup and TransferText only refer to tables in the shell
mdb.

Code references to CurrentDB will have to be change to CodeDB.

(david)



"PeterM" wrote in message
...
This is fascinating...

If I understand you correctly...I can take my existing .mdb (80meg) and
break it into smaller .mdb's and then create a master .mdb that calls the
forms in one of the smaller .mdb's.

In order to do this, I need to add a reference to all of the smaller
.mdb's
in the master .mdb (Tools References). do I have it correct?

Is there some documentation or an example that you know of I could see?

Thanks David!

"david epsom dot com dot au" wrote:

Our application is about that big (80). Zipped, it is about
12 meg. Compressed to self extracting executable with rar,
then zipped, it is about 10.

The application has a shell mdb/mde, 4-12 application
mde's at 1-10MB, and a library mde at 10MB.

Each application module references the library mde
(tools, references).

The shell references all of the application modules
and the library module.

For ease of installation and support, we require all
clients to install to the specified program files
folder.

When using the shell as an mdb, we can replace any
application mde, provided the library mde does not
change.

If you use application mdb modules, then you could
also update the library module without changing all
application modules.

Or you might not have enough shared code to justify
a library module.

We also have code in DLL's: these may be updated
independently of the mde's.

Within the application modules, some forms call other
forms. From the shell, application modules are called
from the menu system.

(david)


"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options. I
have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg.
It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or
find
something that will convert the Acess app to another language such as
VB
.NET
or JAVA where we can have a thin client or where I can break the form
in
the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank
you
in advance for your advice!

And, FWIW, we use a bound control for the Report
Logo. The actual bitmap is stored in the database,
and clients use their own bitmaps. We have hundreds
of reports, but normally just two copies of the
bitmap: a report header bitmap, and a report footer
bitmap. Every report that uses the bitmaps links
to the bitmap table. In most cases, I didn't
write the query, and there is a 'cartiesion
join': there is only one record in the bitmap
table, and the table is just included in the
report source.

(david)



"david epsom dot com dot au" david@epsomdotcomdotau wrote in message
...
Our application is about that big (80). Zipped, it is about
12 meg. Compressed to self extracting executable with rar,
then zipped, it is about 10.

The application has a shell mdb/mde, 4-12 application
mde's at 1-10MB, and a library mde at 10MB.

Each application module references the library mde
(tools, references).

The shell references all of the application modules
and the library module.

For ease of installation and support, we require all
clients to install to the specified program files
folder.

When using the shell as an mdb, we can replace any
application mde, provided the library mde does not
change.

If you use application mdb modules, then you could
also update the library module without changing all
application modules.

Or you might not have enough shared code to justify
a library module.

We also have code in DLL's: these may be updated
independently of the mde's.

Within the application modules, some forms call other
forms. From the shell, application modules are called
from the menu system.

(david)


"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options. I
have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg. It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or
find
something that will convert the Acess app to another language such as VB
.NET
or JAVA where we can have a thin client or where I can break the form in
the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have. Thank
you
in advance for your advice!

So the shell would simply have a custom menu calling forms in the application
modules?

What is contained in the Application modules? forms? queries? reports?
tables? modules? macros?

What is contained in the Library module? forms? queries? reports? tables?
modules? macros?


"david epsom dot com dot au" wrote:

You can't directly call a form (it was never easy, and
the feature was disabled in A2003). Instead, you need
to have a function in each module to open forms and
run reports. And nothing appears in the database window
of the shell - you need to add items to a custom menu
to call your application entry points.

In order to do this, I need to add a reference to all of the
smaller .mdb's in the master .mdb (Tools References).
do I have it correct?

Yes.

Is there some documentation or an example that you know of I could see?

Not that I can think of. Access version 2.0 was built like
this, so you could see all of the wizards and utilities as
examples, and even in A97 some of the wizards and utilities
were built sort of like this, but not any more.

BTW, when you have all your mdb's loaded, you can also call
down and sideways from one to another, using Run or Eval.
Code can call up directly.

DLookup and TransferText only refer to tables in the shell
mdb.

Code references to CurrentDB will have to be change to CodeDB.

(david)



"PeterM" wrote in message
...
This is fascinating...

If I understand you correctly...I can take my existing .mdb (80meg) and
break it into smaller .mdb's and then create a master .mdb that calls the
forms in one of the smaller .mdb's.

In order to do this, I need to add a reference to all of the smaller
.mdb's
in the master .mdb (Tools References). do I have it correct?

Is there some documentation or an example that you know of I could see?

Thanks David!

"david epsom dot com dot au" wrote:

Our application is about that big (80). Zipped, it is about
12 meg. Compressed to self extracting executable with rar,
then zipped, it is about 10.

The application has a shell mdb/mde, 4-12 application
mde's at 1-10MB, and a library mde at 10MB.

Each application module references the library mde
(tools, references).

The shell references all of the application modules
and the library module.

For ease of installation and support, we require all
clients to install to the specified program files
folder.

When using the shell as an mdb, we can replace any
application mde, provided the library mde does not
change.

If you use application mdb modules, then you could
also update the library module without changing all
application modules.

Or you might not have enough shared code to justify
a library module.

We also have code in DLL's: these may be updated
independently of the mde's.

Within the application modules, some forms call other
forms. From the shell, application modules are called
from the menu system.

(david)


"PeterM" wrote in message
...
I'm finally at the stage where I need to investigate other options. I
have
consultants in the field all over North America and our Access app is
critical to our companies function.

The problem is that the file size for the .mde is now over 80 meg.
It's
becoming a major problem for people in the field to download a thick
client 2
or 3 times a week.

I either need a way to split up the application into smaller pieces or
find
something that will convert the Acess app to another language such as
VB
.NET
or JAVA where we can have a thin client or where I can break the form
in
the
Access app into smaller files.

I would really appreciate any suggestions that anyone might have.
Thank
you
in advance for your advice!

"PeterM" escribió en el mensaje
...
I've removed all graphics from the forms and reports which dropped it down
about 5 meg only.

Is there a way in Access to see if a query, form, report, macro and module
are referenced in the app? If I could determine the dead items, I could
reduce the size by deleting them?

Don't think I'm doing anything strange..........

"Rick Brandt" wrote:

PeterM wrote:
Actually, the 80 meg .mde is just the front end...we have our tables
out on a server provided by a host provider. The app has over 125
forms, 300 queries and about 45 tables.

You have something strange in your design. My main app has way more
objects
than that and weighs in at a little over 20 MB on a fresh MDE. Do you
have lots
of embedded images or something?

--
I don't check the Email account attached
to this message. Send instead to...
RBrandt at Hunter dot com

"PeterM" wrote in message
...
So the shell would simply have a custom menu calling forms in the
application
modules?


Yes, although we actually have an autokeys and an autoexec macro,
and a macro to check references, and the re-linking form, and the
"keep links open" form and some other stuff.



What is contained in the Application modules? forms? queries? reports?
tables? modules? macros?

Yes, but the only macro's are for debug/development. I don't
know if there is an easy way to call macro's in a reference. And
you need modules, to contain the entry points for the forms and
reports.



What is contained in the Library module? forms? queries? reports? tables?
modules? macros?

Yes. I've gotten all of the reports out, that was easy because all report
calls are table driven through the report manager, but I've still got forms
for all the reference data. I want to move the forms out as well, but
because the application modules have direct calls to the entry points, the
calls from the application modules will have to change, so it is a political
decision.

(david)

Another "offender" for bloating DB size is the textures that the Wizard
"lures you into using" on Forms. When I put examples on the net, I generally
go in and remove the "background picture" and just choose a pleasing soft
color... and it does decrease the size -- a courtesy to those who download
my examples.

Larry Linson
Microsoft Access MVP

"PeterM" wrote in message
...
I've discovered that the reports are the offenders. I only have 22
reports
and they don't appear to be anything strange. There is our company logo
on
each of them and I'm hoping that will reduce the size.

When I made a copy of the .mdb and then deleted the reports, the file size
went from 68 meg to 38 meg.

Looks like I'm gonna have to create a separate .mdb with just the reports
in
them and distribute that separately.

Unless you have any other ideas? Regardless, thank's for taking the time
to
help!

"(PeteCresswell)" wrote:

Per PeterM:
I created a copy of the .mdb and then deleted all forms, queries,
reports,
macros, modules, etc so that the app is empty. It's now 19meg when it's
empty. I'm using Access 2002.

That's the same version my app was running under.

Have you tried compacting?
--
PeteCresswell