Displaying data from one table to another

[GerthKe]

Hello, a real novice question here (I know there are similar ones here, but those havent helped me), I'm trying to develop a sort of error reporting solution with 3 tables, the solution is as follows: theres one table, where the user submits an error ( lets call it table A), fills out the neccesary fields, saves and leaves, now, theres table B for mechanics, who see the the record from table A, they fill out the solution for the problem, save it, and then theres table C, wich is for purely viewing purposes only, so in short, 

table A has 8 fields, that are shown on table B, wich also has 8 additional fields and table C shows the total 16 fields from table B, but my problem is, the data isnt showing, when I create a record in table A, it doesnt display it on Table B, and therefor theres nothing on Table C either, I've created relations between all 3 tables, so my problem probably lies there, so my question is, how do I get it working? any help is highly appreciated. 

[comment]

Please don't use abstract names for your tables. It makes it very difficult to follow your explanation. Call each table by what does a record in the table represent.

 

theres one table, where the user submits an error ( lets call it table A), fills out the neccesary fields, saves and leaves,

 

That would be the Errors table. Or Problems. Or more likely Malfunctions, if these are later fixed by mechanics.

 

 

theres table B for mechanics, who see the the record from table A, they fill out the solution for the problem, save it,

 

Why do we need a separate table for this? Will there ever be more than one solution to a specific problem? Or a solution that solves more than problem? Also, will there be many problems left without any solution at all?

 

 

then theres table C, wich is for purely viewing purposes only,

 

Again, what is the exact purpose of this table? We sometimes (read: rarely) use an auxiliary table for special display needs (e.g. a calendrical view), but normally you would just use a layout of the table where the records are in order to view those records (and the records related to them, using a portal).

[GerthKe]

I've separated all 3 so people can only access the tables they are supposed to and input data they are supposed to, for example the machine operators can submit malfunctions and view them in table C, but cant access the mechanics table and cant edit old records, the viewing table is there for history & reference, and in the future the info will be displayed on a tablet next to malfunctioning machine. What i'm trying to do is replace a pen & paper solution and sort of copied the logic behind into filemaker. 

[comment]

What i'm trying to do is replace a pen & paper solution and sort of copied the logic behind into filemaker.

 

That's usually not a good idea. Otherwise why move to a computerized solution?

 

You haven't answered my questions, though. When designing a relational database, the most crucial aspect is cardinality: how many of each x are there for each y?

 

 

---

Added:

 

As a pure guess, I would say you should have the following tables:

 

Equipment -< Malfunctions -< RepairLog

 

This is assuming we want to log each repair (or repair attempt) performed on a specific machine to solve a specific malfunction. 

Edited March 12, 2014 by comment

[GerthKe]

The reason is simple - to get rid of the stacks of paper. Instead of having stacks of paper next to individual machines people can rather check the logs to see what has been done. and there will be only 1 solution for 1 problem, to answer that previous question. And yes, thats the setup of tables I have. 

[comment]

there will be only 1 solution for 1 problem

 

Then the RepairLog table is redundant. You just need to add the fields describing a repair to the Malfunctions table. Then use field level access to deny the great unwashed masses the privilege of viewing( ?) and/or editing of those fields. You will probably want to use different layouts for each type of user, in addition to the security measures.