Plateforme Level Extreme
Abonnement
Profil corporatif
Produits & Services
Support
Légal
English
Reservation System - improved method for multi-users???
Message
De
17/02/2000 21:03:27
Jill Derickson
Software Specialties
Saipan, CNMI
 
 
À
Tous
Information générale
Forum:
Visual FoxPro
Catégorie:
Autre
Titre:
Reservation System - improved method for multi-users???
Divers
Thread ID:
00333867
Message ID:
00333867
Vues:
42
Hello all...

I am rewriting a multi-user FPW 2.6a tourist submarine reservation system in
VFP 6. The sub has 45 seats for each dive, and dives CANNOT be overbooked.

Information in a "group reservation" (GROUP.DBF) includes:
- group number (primary key)
- the date and time of the dive
- the number of people in the group
- other info (type of reservation, agency, agent, etc.)

For each person in a group reservation, there is a record in PERSON.DBF;
information includes:
- group number (foreign key)
- identifying information (Name, hotel)
- other info (type of passenger, income, etc.)

When a user adds a new reservation, or increases the number of people in a
group reservation previously made, they enter the group size first. If
there are not enough seats available, I want to notify them THEN, before
they enter any further information. So I want to "reserve" the seats in the
data...but, of course, if they cancel before they are completely done
entering all required info, (or the system crashes), I need to unreserve the
seats.


In the old system, in general, once the user enters the number of seats
required, the availability of seats is determined and records are written to
the above files - with some fields empty so they can be identified as not
completed in case of system crash.

An entry in a file, RESERVE.DBF, is used during the time that these entries
are written to the 2 tables - RESERVE.DBF contains a record with the date
and dive of the reservation entries being made. The RESERVE.DBF record is
locked before the system determines the availability of the seats (and
unlocked once the entries are written). If another user tries to make a
reservation for that date and dive, and the record is busy for 10 seconds,
the second user gets a message to try again later. (I haven't heard of a
user receiving this message in the current system.)

Once the entries are written to GROUP.DBF and PERSON.DBF, the RESERVE.DBF
record is unlocked and other users may make new seat reservations for that
dive. GROUP.DBF and PERSON.DBF information is completed by the user, and
the entries are updated (or the user cancels and records deleted).

At system start-up time, if GROUP.DBF and PERSON.DBF can be opened
exclusively, incomplete records are deleted.

I'm looking for any suggestions/ideas on how to improve the implementation
of this multi-user strategy.

TIA! J
Suivant
Répondre
Fil
Voir

Click here to load this message in the networking platform