Disable input after 5 entries

  • Thread starter Thread starter Harvard
  • Start date Start date
H

Harvard

I'm working with 2 tables. One contains Table Reservations, and the second
contains the People that will be sitting at the tables. Is there a way to
disable assigning people to a table after 5 people have been reserved for a
particular table?
 
Yes there is. If you are assigning people via a form, put a check in the form
(query the table to see how many assigned so far).
In fact, each table could have its own 'max people' and you could stop after
the 'max people' for the table. So you could have different sized tables
taking different numbers of people.

-Dorian
 
Yes there is. If you are assigning people via a form, put a check in the form
(query the table to see how many assigned so far).

Isn't a 'forms' approach OT for the 'tables' group <g>? Regardless,
don't you think that simple data rules such as these should be
enforced using table constraints? I do.
In fact, each table could have its own 'max people' and you could stop after
the 'max people' for the table. So you could have different sized tables
taking different numbers of people.

Good point. Here's a demo of two approaches to enforcing such 'dat-
driven' limits using table constraints:

http://groups.google.com/group/microsoft.public.access/msg/1d4430dc8b50ba8f

Jamie.

--
 
That works if the number of seats per table is a constant. Most people need
more flexibility so the rules become more complicated. But in any event, if
the OP is using Jet, table level rules are limited.
 
To give this process more flexibility, I would assign a TableType field
which indicated the number of seats for each table. The default can be 5 if
that is the most common size. To handle this without running queries, I
would add a control in the footer of the subform that counts the number of
rows in the seating subform for the current table. In the BeforeUpdate
event of the subform, I would check the count in the subform footer and
disallow the add if the table has reached capacity.
 
That works if the number of seats per table is a constant. Most people need
more flexibility so the rules become more complicated.

Please take another look at the link I posted. In the demo the seating
capacity for each class is a column (seating_capacity) therefore is
not a constant. This is what I mean by 'data driven'.
But in any event, if
the OP is using Jet, table level rules are limited.

Do you mean a Table Validation Rule? It's a bit of a misnomer becasue
it is actually a row level rule i.e. can refer is values in the same
row in the same table but not other rows. Again, take another look at
the link I posted: the second approach uses a Jet CHECK constraint,
which are truly table level in that they can refer to values in other
rows in the same table (also rows in other tables).

Jamie.

--
 
Back
Top