Multiple user setup

[Guest]

As a newbie and short of time, I'd like to be on the right track as I design
this DB. The purpose of the DB is to accumulate records of student behavior
issues in our middle school. Each of about 60 staff members should be able
to create new records regarding specific incidences of misbehavior. Once
created and saved the records cannot be edited. The DB will be made up of a
table of student information, a table of staff names, a table of behavior
categores, a table of specific behavior infractions. There will also be
tables regarding consequences but these would not be on the staff input form
which I think should be a single record form. A different, continuous view
form would include all student behavior records and would allow staff to
filter and review behavioral history of a student.
Questions:
- Should this/can this whole DB be on the server?
- Should the DB be split?
- How would Access deal with multiple staff members accessing the data input
form at about the same time.
- Would an html data access page work better here?
Hope this is enoough info from which you can advise me on direction.
Thanks, H.

 

[John Vinson]

As a newbie and short of time, I'd like to be on the right track as I design
this DB. The purpose of the DB is to accumulate records of student behavior
issues in our middle school. Each of about 60 staff members should be able
to create new records regarding specific incidences of misbehavior. Once
created and saved the records cannot be edited.

You can use Access security (read the Security FAQ *with great care*,
*TWICE*, and follow it to the letter), and set your Forms to "Allow
Additions" True, and "Allow Updates" False - but totally and
uncrackably preventing editing of existing records is both difficult
and problematic. Do you really mean that once a record is entered, it
can never be changed for any reason - such as a mistaken identity, the
discovery that a witness was lying, etc.?

The DB will be made up of a
table of student information, a table of staff names, a table of behavior
categores, a table of specific behavior infractions. There will also be
tables regarding consequences but these would not be on the staff input form
which I think should be a single record form. A different, continuous view
form would include all student behavior records and would allow staff to
filter and review behavioral history of a student.

Get the table design right first - sounds like you're on the right
track - and then worry about forms and queries. You'll probably find
need for more of these as you go along.

Questions:
- Should this/can this whole DB be on the server? See next question
- Should the DB be split?

It should be split: the tables - backend - mdb file would be on the
server, and multiple copies of the frontend would be distributed.

- How would Access deal with multiple staff members accessing the data input
form at about the same time.

With aplomb and ease, usually. If two users attempt to update the SAME
RECORD at the same time, the second one to try will get an error
message.

- Would an html data access page work better here?

Maybe, but I'd go with Access.


John W. Vinson[MVP]

 

[Guest]

Thanks John, Good point on the "no editing". I'll have to think about it all.

 

[John Vinson]

Thanks John, Good point on the "no editing". I'll have to think about it all.

What you may want to do is to have several classes of users: some who
can only read and not update data, others who can insert data but not
edit existing data, others who are authorized to update data. The
security model handles all of these cases.

John W. Vinson[MVP]

 

[Guest]

In the data input form, I've actually set records up not allow update or
delete but to allow addition. I was trying to avoid accidental changing of
the record above if the form was set to continuous view. You're right about
staff needing the ability to edit input. I'm working on a single view input
form but a different form for viewing student history and editing input.
I'll look at the security FAQ mentioned earlier when I get to that point.
Thanks. H

 

[John Vinson]

In the data input form, I've actually set records up not allow update or
delete but to allow addition. I was trying to avoid accidental changing of
the record above if the form was set to continuous view. You're right about
staff needing the ability to edit input. I'm working on a single view input
form but a different form for viewing student history and editing input.
I'll look at the security FAQ mentioned earlier when I get to that point.
Thanks. H

Just another possibility - you can set a form's Data Entry property to
True; this will let users add new records, but they will not be able
to edit (or even SEE) existing records. You could have a second form,
or toggle the form's properties, with AllowEdits, DataEntry and
AllowAdditions all False for a "look but don't touch" form.

John W. Vinson[MVP]

 

[Guest]

Another good thing to try. Thanks. I'm feeling pretty good as I've split
the DB and the parts work together on my home network. Starting to come
together.

Here's a different question. I started out learning Access with training
CDs. Somewhere in these I was told to never build a form directly from
tables and never put a combo box in a table. Turns out I did both these
things to get to where I'm at now and it works great. I've also tried doing
it other ways, i.e., just putting combo boxes in a form but I can't get that
to work right. Now, when I complete a sample record, it gets saved back to
the table that has all the fields together in one table. And it seems this
table needs to exist as a storage contaner. Am I missing something?

 

[John Vinson]

Another good thing to try. Thanks. I'm feeling pretty good as I've split
the DB and the parts work together on my home network. Starting to come
together.

Here's a different question. I started out learning Access with training
CDs. Somewhere in these I was told to never build a form directly from
tables and never put a combo box in a table. Turns out I did both these
things to get to where I'm at now and it works great. I've also tried doing
it other ways, i.e., just putting combo boxes in a form but I can't get that
to work right. Now, when I complete a sample record, it gets saved back to
the table that has all the fields together in one table. And it seems this
table needs to exist as a storage contaner. Am I missing something?

I'm not sure what you're saying.

Having a Lookup Field (combo box) in a table makes putting a combo box
onto a form one or two mouseclicks easier, but it is *perfectly*
possible to create combo boxes on forms without having the lookup
field. What problems did you have? How did you try to create the
combo?

You say "complete a sample record... gets saved back to the table..."
I have no idea what you're getting at. All data is stored in tables,
and only in tables; any bound control on a Form will save data to a
table. Just what's going on with this sample record? What controls do
you have on the form? What's the Recordsource of the form, and the
RowSource of the combo box?

John W. Vinson[MVP]