How big is too big for database size?

[Jennifer]

I have a database that hovers between 9 and 10 megs, and
it seems to be giving me frequent errors - have even had
to recover it from back-up a few times. Does this have to
do with the file becoming too large for Access to handle,
or is it more likely problems within the database. I
compact it weekly, so I don't think that's the problem.

Is there anyone out there who works with larger databases
without any problem. I didn't think 9-10 megs is very big,
but I'm starting to worry.

 

[Dirk Goldgar]

I have a database that hovers between 9 and 10 megs, and
it seems to be giving me frequent errors - have even had
to recover it from back-up a few times. Does this have to
do with the file becoming too large for Access to handle,
or is it more likely problems within the database. I
compact it weekly, so I don't think that's the problem.

Is there anyone out there who works with larger databases
without any problem. I didn't think 9-10 megs is very big,
but I'm starting to worry.

9-10MB is *tiny*! If you're having frequent corruptions, something else
is going on. Is this database being accessed across a network? Then
maybe there are problems with the network or with the NIC on a
particular PC. Is this database being accessed by multiple users? Then
it's best to split it into a separate front-end and back-end, store only
the back-end on the server, and give each user her own copy of the
front-end.

Tell more about your database, your architecture, and your users, and
maybe some other advice will present itself.

 

[Larry Daugherty]

File size is not your problem.

Most likely one or more users are powering off their systems or losing power
while they have recordsets open. Other possibilities are flaky hardware at
any level or flaky network operation.

HTH

 

[Jennifer]

-----Original Message-----


9-10MB is *tiny*! If you're having frequent corruptions, something else
is going on. Is this database being accessed across a network? Then
maybe there are problems with the network or with the NIC on a
particular PC. Is this database being accessed by multiple users? Then
it's best to split it into a separate front-end and back- end, store only
the back-end on the server, and give each user her own copy of the
front-end.

Tell more about your database, your architecture, and your users, and
maybe some other advice will present itself.

--
Dirk Goldgar, MS Access MVP
www.datagnostics.com

(please reply to the newsgroup)


Thanks for the questions. I didn't think the size should

be a problem.

The database is used by multiple users on a network. There
are about 5 users who navigate among forms to enter data
and/or retrieve reports. I am the only one who needs to
access the back-end stuff. I am not an Access expert - I
just do what I can to keep the database functional and
user-friendly.

I'm interested in the idea of splitting the front-end and
back- parts. Is that an easy thing to do?

 

[Dirk Goldgar]

The database is used by multiple users on a network. There
are about 5 users who navigate among forms to enter data
and/or retrieve reports. I am the only one who needs to
access the back-end stuff. I am not an Access expert - I
just do what I can to keep the database functional and
user-friendly.

I'm interested in the idea of splitting the front-end and
back- parts. Is that an easy thing to do?

Quite easy -- there's a wizard that handles all the nitty gritty
details. And if you currently have one physical database file, on a
server, being opened simultaneously by multiple users, then you should
definitely split the database as the current arrangement is quite
susceptible to corruption.

To split the database, open it and click menu items Tools -> Database
Utilities -> Database Splitter. The wizard will take you through the
process, which is generally quick and painless. You then put the
back-end (containing just the tables) on the server, and install a
separate copy of the front-end (containing all the forms, reports,
queries, and modules) on each user's hard disk. By way of data, the
front-end contains only links to the tables in the back-end database.

Tony Toews has written a page discussing split databases, with links to
other good sources of information. Here's the URL:

http://www.granite.ab.ca/access/splitapp.htm

While you're there, you may want to scan his performance tips, as some
of them apply particularly when you're working in a split-DB
environment:

http://www.granite.ab.ca/access/performancefaq.htm

 

[Larry Linson]

... Other possibilities are flaky
hardware at any level or flaky net-
work operation.

Alas, flaky network staffs and their equally flaky network setups are not
nearly so easy to deal with as the other causes, but I did see one operation
where a network staff "housecleaning" had some extremely beneficial effects.
(However, the Access benefits were only side benefits; it wasn't Access
problems that got their management stirred up.)

 

[Ned]

-----Original Message-----
I have a database that hovers between 9 and 10 megs, and
it seems to be giving me frequent errors - have even had
to recover it from back-up a few times. Does this have to
do with the file becoming too large for Access to handle,
or is it more likely problems within the database. I
compact it weekly, so I don't think that's the problem.

Is there anyone out there who works with larger databases
without any problem. I didn't think 9-10 megs is very big,
but I'm starting to worry.
.

Dont worry I have a database that is over 1 Gig and it is
still running without any problem. I'm even using it for
multi-users and the file access time is still fast.
Although I was told that the maximum capacity for access
is 1 Gig, I have exceeded it. But to be safe dont let the
file size go over 1 Gig.

 

[Dirk Goldgar]

Although I was told that the maximum capacity for access
is 1 Gig, I have exceeded it. But to be safe dont let the
file size go over 1 Gig.

Is that an Access 97 database, or Access 2000/2002? The maximum size
increased to 2GB with the later versions.