|
Time in, time out, and time worked introduces a redundancy, which is not good. Anything you can derive from other fields you don't need in the table. So long as they haven't clocked out (time out blank), time worked is zero. Otherwise, it's time out minus time in minus cumulative breaks. You need to sit down and think about the data. That's part of the design, and comes before coding. If you use the proper modern DB design techniques or revert to the older normalization procedures, you will have a robust system that isn't likely to come back and bite you in the azz. I realize that this is a classroom project and not a commercial venture, but if you can hack the time/effort required, it'll pay off in real life later.
This may well belong in the Delphi forum if it gets down to a coding issue, but, really, design is key, and language is chosen for appropriateness or because it's otherwise required by the client (who may be your teacher).
You're the one to consider all these issues and make the decision, ultimately. Any advice you need, ask for. It's one more set of inputs to think about.
|