Recent content by XPS35

Welcome. I don't know how much experience you have in designing and building database applications. Don't underestimate the complexity involved. My advice would be to leave this to the IT department. It's their job!

Just a reminder to post #1. In order to achieve this it is not just "nice" to have the history but necessary. As I said before (#2), an option is to store the shift, position etc. of an employee in a month into the tblStat. Option two is having junction tables with dates to store the history...

Looks better 👍 But you still have to solve the issues I mentioned in my previous posts.

If you've read about normalization and relationships, I'm afraid you haven't quite grasped it. A relationship connects similar data with equal values. For example, if you want to record an employee's shift, you include the ShiftID field in the employee table and create a relationship with the...

Are users able to change the status?

Part of the solution could be to store the current employee data in the tblStats. But before thinking about solutions, you need business rules. Like: how to deal with employee data that changes during a quarter. It's a common problem that inexperienced developers start building a database too...

It's quite a story (and one that sounds familiar to me). One of the main problems is that you only think in terms of static personnel data, while it's actually dynamic. In tblStats, you record the EmployeeID. The employee table contains various attributes (position, assignment, and others) you...

Why don't you store a new record? Now you are missing the initial values in the history.

Can it happen that only one of the spouses is a member?

Since this topic has been open for a while, I've had plenty of time to think about it ;) What I'm thinking now is that you undoubtedly also record the customer's place of residence. This also establishes the county, and with the county, the market. To prevent input errors and minimize user...

To do this, it's necessary to have a table that specifies which market a county belongs to. I don't understand from the question whether this is the case. If it is, then you don't need to do anything. The county-market relationship is already established, and you don't need to specify it again...

Please provide a database that is working.

Check your SQL. There is no such relationship.

It seems the original poster has left the forum and is trying his luck elsewhere. See HERE. I wouldn't waste any more time on this question.

It is an error. Clockings are related to a member and a member can have one or more clockings. So there is a one to many relationship between members and clocking. The field that connects them is barcode. All clockings with the same barecode belong to one member. Connecting on amounts is wrong...