Hi Michael,
I have done something similar to what you are describing. Your approach is very different however. Based on my memory, here is a scenario of what I did (I don't have it handy):

Sports facilities have racketball courts that can be reserved for half-hour increments. Reservations can made at any facility for any court at any other facility. The reservations can be cancelled. The reservations must be tracked by facility, court, and reservee.

(Only pertinent fields shown)

Facility Table
fac_key && guid
fac_id && unique
fac_name
court_id && matches courts table court_id shows what courts a fac has

Courts Table
court_key && guid
court_id && has a matching record in the facility table
court_name

Reservations Table
res_key && guid
res_number && given at time of reservation
court_id && matches record in courts table
res_id && matches slots_key
cust_id && customer id in customer table

Customer Table
cust_key
cust_id
cust_last
cust_first
cust_mi
cust_addr1
cust_addr2
...

Slots Table
slots_key && guid
court_id && court (24 records for each court for each day in month)
slots_hperiod && the period i.e. 200301011430 = 2:30-3:00pm on 1/01/03
slots_rsvd && logical

Primary Indices
facility: fac_key
courts: court_key
reservations: res_key
customer: cust_key
slots: slots_key

Relations
courts.court_id = facility.court_id
courts.court_id = reservations.court_id
courts.court_id = slots.court_id
reservations.cust_id = customer.cust_id
reservations.res_id = slots_rsvid

Every month 24 (x the number of days in the month) records are added to the slots table for each court that exists in the courts table. These records become the slots_hperiod records and are designated by date and hour and period 1 or 2 (first half hour, 2nd half-hour of the hour) such as 200301011430 && year 2003/January/1st/2nd half-hour of 2:00pm (1430). When a customer makes a reservation for a court, they pick a date/time and a court. If the customer picks 1430-1500 hrs, january 1st, 2003, in court A1 then the following is done:

The slots table is searched for all records that match slots.court_id='A1' .and. slots_hperiod = "200301011430 .and. slots.rsvd=.F. (not reserved)

If the slot is not reserved, then the customer's id is stored to a reservations table in cust_id along with the court_id. The res_id stored in the reservations table is the slots_key value for that time period in the slots table. The key field is done, because even if the reservation is cancelled, only one record will always remain in the slots table for the time period. The slots_rsvd is changed to .t. for reserved and to .f. when open or a reservation was cancelled. If a customer's reservation is cancelled, it is deleted from the reservations table and the slot_rsvd field in the slots table is changed to .t.

Obviously by looking at this you can see that a lot more is done in addition to what I mentioned, but the general layout worked well for me and it is still in use at a location that has 23 facilities and over 100 courts. I am only posting this to give you some other ideas on how you could accomplish the same thing without having to worry about recreating key records.



>Cindy,
>
>I'm designing a small sports booking system for a friend of mine. On one of the facilities, I have a grid, in one column I have all the times that facility can be used. Beside that, I have the name of the person using that facility at that time.
>
>You see, this grid is populated using an SQL select statement, and is therefore temporary. When I click on a date, and then time, all of the information is added to the table, permanently.
>
>This is why the table needs a (date + time) as the primary key. Now the user has told me that often a booking is made and then soon before use, is cancelled, and another person then makes a booking for that facility at that time.
>
>For this reason, I must be able to permanently remove the record immediately. I was thinking if I use COPY STUCTURE TO "tempTable", then use information from tempTable. Then if I want to delete, I can do it with no index violation errors? At the end of all, I can copy the information back to the permanent table. This however I believe, is what the PACK command does!!
>
>I'm sorry if this problem is a bit soft, but I have only recently started using VFP and this is my first project.
>
>From reading this information you have any suggestions, they are all welcomed.
>
>Thanks again,
>Mick