Upgrade from FPD2.6 - methodology change

[cricket]

I have a system running under fpd2.6 multi-user which is used to collect details of time worked by individuals on various jobs , so as to calculate the cost of each job.

The tables are (greatly simplified)
Person(2 fields ID No & Name),
Job (2 fields job No. & Description) and
Time (fields ID No, date, job No., time)
The employee returns a timesheet which should account for 8 hours ( not always so - e.g. late, sick, half-day holiday).
This seems simple except I must account for all 8 hours for each person. I use the expedient of a temporary empty database on the local drive, enter the records from the timesheet, and add in a record for any shortfall in time returned with a dummy job no..

I then APPEND these records to the server time.dbf.

If I must ammend a records, I have to copy all the records for the particular individual and the relevent date from the server Time.dbf to the local dive and mark as deleted on the server.
I change the details locally, recalculate any unaccounted time and APPEND to the server Time.dbf. I I wish to make no changes, then I must RECALL ALL for the person&date combination


Is there a cleaner and neater way to handle this in vfp?

 

[RLG07734]

You could try using SQL commands to maintain the databases.
1. select the appropriate records from the server dbf's to a local cursor file.
2. Edit, delete, append records to that cursor file to adjust your employee's times.
3. Send the records back using UPDATE for the existing records and INSERT for the new ones.

I'm not sure how much you can alter the tables on the server, but if you can...
create 2 more fields in time.dbf, one for a unique identifier for each record and the second as a deleted record field (both character fields). populate the unique identifier with something that will be unique to only that record, and the deleted identifier with either '1' or 'Y' to indicate the record has been deleted.

after you have changed the data, you can update existing records based on the unique identifier already existing in the server dbf, and insert records that do not already exist. the deleted identifier signals the system that the record is marked as deleted so your report routines can use that as a filter.

one advantage of the deleted identifier is that new records can see these and overwrite them with the new data, so you don't have to constantly append and pack.

with a little programming work, this works well. I have dbf's that have 4-5 million records, and rather than deleting, appending, etc I just overwrite marked records with new data.

hope this helps

Ron