Auto Compact with Runtime Access?

G

Gordon Jones

I have a new user using Access Runtime 2002. Her App_be.mdb is 17+ MB, and
should be about 2.5MB. It won't zip to a smaller size. My App is set up to
Auto-compact on close. Is that supported in Runtime?
 
D

Douglas J Steele

Assuming that you're using the normal naming convention, where _be indicates
that it's the back-end database (which contains only tables) that is
connected to from a front-end (which contains the queries, forms, reports,
macros and modules), Auto-compact only compacts the front-end, not the
back-end.
 
6

'69 Camaro

Hi, Gordon.
My App is set up to
Auto-compact on close. Is that supported in Runtime?
Click to expand...

Yes. And if you ever want to test some whether some feature exists or works
correctly in the Runtime version of your application, create a "Runtime"
shortcut to activate your database application in Runtime mode. To do so,
create a new shortcut and in the "Target:" field, try (watch out for word
wrap, as this is all one line):

"C:\Program Files\Microsoft Office\OFFICE10\MSACCESS.EXE" "C:\Work\MyDB.mdb"
/runtime

.. . . where C:\Work\MyDB.mdb is the path and file name to your database.
(And yes, the full path to the executable is _required_ when there's a
command-line argument to be passed.) The database will open in Runtime mode.
This method works in all Jet 4.0 database versions for testing the Runtime
version of a database application.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.

(Please remove ZERO_SPAM from my reply E-mail address so that a message will
be forwarded to me.)
- - -
If my answer has helped you, please sign in and answer yes to the question
"Did this post answer your question?" at the bottom of the message, which
adds your question and the answers to the database of answers. Remember that
questions answered the quickest are often from those who have a history of
rewarding the contributors who have taken the time to answer questions
correctly.
 
G

Gordon Jones

Thanks for the prompt responses. Yes, my app.mde has an app_be.mdb back end.
With an mde, why would it need compacting? And how, other than having her
send me her .mdb file, can I get it compacted?
 
6

'69 Camaro

Hi, Gordon.

The back end is where the data resides. Multiple record deletions, updates
and inserts can leave "blank" spots between records and within records.
Compacting the database is the only way to reclaim these blank spots.

If you set "Compact on Close" on the back end database file before shipping
the application to her, then the user only needs to open the back end
database file manually and then close it. "Compact on Close" applies to the
Access GUI opening/closing a database file, not to other database files that
may open it through a data connection, such as a table link. Your front
end's "Compact on Close" setting has no effect on any other database files,
including the back end.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.
 
6

'69 Camaro

Hi, Gordon.

And just in case you forgot the "Compact on Close" setting on the back end
before shipping the application, don't worry. Your user has two options.
Please see the tip "Compacting the Database" on this Web page:

http://www.Access.QBuilt.com/html/gem_tips.html#Compacting

And don't forget this setting the next time you ship your applications, or
your user might decide the best option is to find a new database developer.
;-)

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.
 
G

Gordon Jones

Hi, Gunny:

Thanks for the previus help on this. I still have a couple of problems.
1. There seems to be no way to open the back-end db in Runtime. If I click
or select "open", all that opens is the Access Runtime window. I don't get
to view the "Database" form.
2. Exiting the program doesn't seem to cause the compress & repair, even
tho it is set to do so.
3. Can you point me to a document that sets out what Runtime can do and
can't do? I have no documentation, and can't find any. For example, my
app.dbe can't make changes to the database structure, so I have an
"upgradeN.mdb" that I distribute when I want to add a variable to a table, or
a table to the db. In the Runtime mode, opening that upgradeN.mdb and
executing the code causes a "Runtime Error " (unnumbered).

I appreciate your help. Thanks again.
 
R

Rick Brandt

Gordon said:
Hi, Gunny:

Thanks for the previus help on this. I still have a couple of
problems.
1. There seems to be no way to open the back-end db in Runtime. If
I click or select "open", all that opens is the Access Runtime
window. I don't get to view the "Database" form.
2. Exiting the program doesn't seem to cause the compress & repair,
even tho it is set to do so.
3. Can you point me to a document that sets out what Runtime can do
and can't do? I have no documentation, and can't find any. For
example, my app.dbe can't make changes to the database structure, so
I have an "upgradeN.mdb" that I distribute when I want to add a
variable to a table, or a table to the db. In the Runtime mode,
opening that upgradeN.mdb and executing the code causes a "Runtime
Error " (unnumbered).
Click to expand...

If you have the ODE there should be a ReadMe or help topic that outlines all of
the differences in the runtime.

An MDE certainly can execute code that implements changes in the BE table
structures. I have apps that do that with no problems.

Your MDE could also execute code to compact the BE.
 
6

'69 Camaro

Hi, Gordon.
1. There seems to be no way to open the back-end db in Runtime. If I
click
or select "open", all that opens is the Access Runtime window. I don't
get
to view the "Database" form.
Click to expand...

The database window is not available in the Runtime version.
2. Exiting the program doesn't seem to cause the compress & repair, even
tho it is set to do so.
Click to expand...

Compact on close works even in the Runtime version, but the database file
may already be as compacted as it's going to get, so it doesn't show any
visible signs of doing it again.
3. Can you point me to a document that sets out what Runtime can do and
can't do? I have no documentation, and can't find any.
Click to expand...

Please see the following Web page:

http://support.microsoft.com/default.aspx?id=162521
For example, my
app.dbe can't make changes to the database structure, so I have an
"upgradeN.mdb" that I distribute when I want to add a variable to a table,
or
a table to the db. In the Runtime mode, opening that upgradeN.mdb and
executing the code causes a "Runtime Error " (unnumbered).
Click to expand...

Add a variable to a table? Do you mean add another field to an existing
table? One cannot do database design changes in the Runtime version.
Design changes require the retail license. If you need to alter tables or
add tables, then create the new database design with your own retail version
and then distribute the new version of your MDE database file to the users.

HTH.
Gunny

See http://www.QBuilt.com for all your database needs.
See http://www.Access.QBuilt.com for Microsoft Access tips.


Gordon Jones said:
Hi, Gunny:

Thanks for the previus help on this. I still have a couple of problems.
1. There seems to be no way to open the back-end db in Runtime. If I
click
or select "open", all that opens is the Access Runtime window. I don't
get
to view the "Database" form.
2. Exiting the program doesn't seem to cause the compress & repair, even
tho it is set to do so.
3. Can you point me to a document that sets out what Runtime can do and
can't do? I have no documentation, and can't find any. For example, my
app.dbe can't make changes to the database structure, so I have an
"upgradeN.mdb" that I distribute when I want to add a variable to a table,
or
a table to the db. In the Runtime mode, opening that upgradeN.mdb and
executing the code causes a "Runtime Error " (unnumbered).

I appreciate your help. Thanks again.
Click to expand...
 
Top