Search results

I'm sorry to say this Jack, but I don't think your model is correct at all. To name just a few key points. You create relationships on non-key fields. If you have a customer table with, for example, CustID as the key, you include CustID as the foreign key in linked tables and link the tables on...

Are the relations from table 1 to tables 2, 3, 4 and 5 one-to-many? If not, why do you have separate tables? I hope the tables have meaningful names. It would have helped us to know the names. Why do you store the address in two tables? What is the meaning of the Display Message field in each table?

It's not clear to me what you want. In the title, you mention "append" and in the question you mention "update." I'm also wondering why you would want that. Generally, storing the same data twice is a bad idea.

Complexity is not the point. Complexity isn't the issue. What matters is: does the model reflect the reality of your situation and your information needs? If a contact can change status and there's a need to maintain the history of those status changes, then you need a specific model. That's...

No, you created a problem. Just make a meaningless key, and store the info (name, type) in the fields where it belongs and nowhere else. No redundancy, no problem.

That is not the way to do it. PositionID, ShiftID and others should not be in the employee table anymore. The positions of an employee, including the current, are now in the history table. You need relationships from employee to the history table on employeeID and from position table to history...

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.