By using this site, you agree to our updated Privacy Policy and our Terms of Use. Manage your Cookies Settings.
434,807 Members | 1,492 Online
Bytes IT Community
+ Ask a Question
Need help? Post your question and get tips & solutions from a community of 434,807 IT Pros & Developers. It's quick & easy.

Is this project to big for Access?

P: n/a
Database purpose is to perform Safety tests on buildings.
5,000 buildings.
20 Test Categories (Fire Safety, Location, Drainage, etc..)
5 TestsGroups per Category (Fields: GroupName, GroupDesc, Code, etc
about 5-10 fields)
3 Test per TestGroup (Fields: TestDesc, txtSummary [50chars],
Result[Boolean], date, etc about 6 fields)

Any building can have up to a total of 300 tests from any combination
of the above Categories, Groups and tests.
New Groups and Tests will be created on the fly by users. (total
number of tests unlikely to exceed 500)
Tests are performed twice per year.
All test need to be archived. (I thought of splitting up the database
by year... 2007tests.mdb, 2008test.mdb etc..)
Current test Data will be compared with recent test data to look for
unusual changes (i.e Fire saftey has declined)

50 users (concurrent 25). Many entering data remotely, so Terminal
Server will be used (Still maintaining a separate front end for each
user).

Can Access handle this?

Paul

May 18 '07 #1
Share this Question
Share on Google+
4 Replies


P: n/a
On 18 May 2007 05:46:37 -0700, go****@comcraft.freeserve.co.uk wrote:

Everything looked good until you said 25 concurrent users. That it
possible (254 is the max), but it will require more than average
skills from the designer / developer to deal with multi-user
conflicts.

Archiving by year is probably not needed. I would keep an eye on the
size of the BE and start archiving oldest projects first, all to the
same ArchiveBE. Keep the size well below the 2GB max.

-Tom.

>Database purpose is to perform Safety tests on buildings.
5,000 buildings.
20 Test Categories (Fire Safety, Location, Drainage, etc..)
5 TestsGroups per Category (Fields: GroupName, GroupDesc, Code, etc
about 5-10 fields)
3 Test per TestGroup (Fields: TestDesc, txtSummary [50chars],
Result[Boolean], date, etc about 6 fields)

Any building can have up to a total of 300 tests from any combination
of the above Categories, Groups and tests.
New Groups and Tests will be created on the fly by users. (total
number of tests unlikely to exceed 500)
Tests are performed twice per year.
All test need to be archived. (I thought of splitting up the database
by year... 2007tests.mdb, 2008test.mdb etc..)
Current test Data will be compared with recent test data to look for
unusual changes (i.e Fire saftey has declined)

50 users (concurrent 25). Many entering data remotely, so Terminal
Server will be used (Still maintaining a separate front end for each
user).

Can Access handle this?

Paul
May 18 '07 #2

P: n/a
"Tom van Stiphout" <no*************@cox.netwrote
Everything looked good until you said 25
concurrent users. That it possible (254 is
the max), but it will require more than average
skills from the designer / developer to deal
with multi-user conflicts.
From the problem description, it seems unlikely that two concurrent users
would be working on the same building/test, etc., and, IIRC, adding two new
records hasn't been a "conflict" problem since Access 95 or maybe Access
2.0.

My experience is that the business logic of most systems is such that
multiple users working on the same record is not nearly as common as people
fear. Take, for example, an electric utilility: if one clerk is handling a
customer call about a particular account, the probability of another clerk
concurrently getting a customer call about that same account is low.

And, in recent-versions, Record-Level locking should be used... to avoid two
users working on Records that just happen to be in the same page of disk
storage.

Larry Linson
Microsoft Access MVP

May 18 '07 #3

P: n/a
Per go****@comcraft.freeserve.co.uk:
>50 users (concurrent 25).
When you mean "Access", that could refer to the front end or the
back end.

Back end, 25 concurrent users, I'd try to sell the user on SQL
Serve as the back end. Not a religious issue.... but my gut
reaction...

Front end... no problem.
--
PeteCresswell
May 18 '07 #4

P: n/a

"Tom van Stiphout" <no*************@cox.netwrote in message
news:76********************************@4ax.com...
On 18 May 2007 05:46:37 -0700, go****@comcraft.freeserve.co.uk wrote:

Everything looked good until you said 25 concurrent users. That it
possible (254 is the max), but it will require more than average
skills from the designer / developer to deal with multi-user
conflicts.
I would think an application for 25 concurrent users would require an above
average developer using a Jet backend or SQL backend. An Access frontend
should not be a problem.
Archiving by year is probably not needed. I would keep an eye on the
size of the BE and start archiving oldest projects first, all to the
same ArchiveBE. Keep the size well below the 2GB max.

-Tom.

Database purpose is to perform Safety tests on buildings.
5,000 buildings.
20 Test Categories (Fire Safety, Location, Drainage, etc..)
5 TestsGroups per Category (Fields: GroupName, GroupDesc, Code, etc
about 5-10 fields)
3 Test per TestGroup (Fields: TestDesc, txtSummary [50chars],
Result[Boolean], date, etc about 6 fields)

Any building can have up to a total of 300 tests from any combination
of the above Categories, Groups and tests.
New Groups and Tests will be created on the fly by users. (total
number of tests unlikely to exceed 500)
Tests are performed twice per year.
All test need to be archived. (I thought of splitting up the database
by year... 2007tests.mdb, 2008test.mdb etc..)
Current test Data will be compared with recent test data to look for
unusual changes (i.e Fire saftey has declined)

50 users (concurrent 25). Many entering data remotely, so Terminal
Server will be used (Still maintaining a separate front end for each
user).

Can Access handle this?

Paul

May 18 '07 #5

This discussion thread is closed

Replies have been disabled for this discussion.