Tek-Tips is the largest IT community on the Internet today!
Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!
-
Congratulations Rhinorhino on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!
Compacrting and Reparing Database on a Network
- Thread starter eelsar
- Start date
Yes, but you run into several issues.
First, your database should be split.
Second, I assume the database is multiuser and you are asking about compaction of the "back-end"...if so, you will need everyone to be out of the database when you compact (otherwise you risk corruption). This makes compact-on-close a very bad idea, you have no real control over when someone is closing the database.
Second, compact-on-close can, on large databases or slow manchines, cause a long delay when closing the database. This may frustrate the user.
The only place you might select "compact-on-close" is the "front-end" database, where the forms, reports, queries, etc. are located. Even then, your front-end shouldn't bloat with usage, and shouldn't need compacting.
First, your database should be split.
Second, I assume the database is multiuser and you are asking about compaction of the "back-end"...if so, you will need everyone to be out of the database when you compact (otherwise you risk corruption). This makes compact-on-close a very bad idea, you have no real control over when someone is closing the database.
Second, compact-on-close can, on large databases or slow manchines, cause a long delay when closing the database. This may frustrate the user.
The only place you might select "compact-on-close" is the "front-end" database, where the forms, reports, queries, etc. are located. Even then, your front-end shouldn't bloat with usage, and shouldn't need compacting.
- Status
Similar threads
- Locked
- Question
- Locked
- Question