> First, you have tables. Then you have forms based on the tables. You
> should not have any reason to move data back and forth between the tables.
[quoted text clipped - 19 lines]
> >
> > Is there a way to "circulate" the information from one form to another?
This can get very complicated. If you have multiple locations, for example,
where the rental can be dropped off.
Secondly, how about future reservations? You also should account for repeat
customers, so you don't have to re-enter the same data.
So I would have at the very least three tables:
1) table for cars, with ID, current mileage, rental rate, other info, size,
color, etc., Y/N fields for currently out and future reservation
2) table for customers, name, address, other pertinent facts
3) table for rentals, date from, date to, carID, customerID.
possible location table, if you have multiple locations. This would a
foreign key in the cars table.
possible reservations table, with carID, dates reserved (in and out).
The critical area will be the from and to dates. If a car is reserved for
future dates then it won't be available, even though it is at your location.
For this I would look at a popup form (on your rental form) tied to the
reservations table, so you could determine if the car will be available
during the current rental agreement. Also, look at some of the calendar
mdbs or links to Outlook's calendar. Google MS Access calendars.
I would really focus on the tables, as they are the foundation of a good
database. The forms will come easy if you have a good foundation.
Damon
>I had posted another question regarding Database Design and Andy Hull had
> given me some guidelines (listed below)... and maybe I didn't understand
[quoted text clipped - 82 lines]
>> >
>> > Is there a way to "circulate" the information from one form to another?