Sometimes Helpful
Windows 8 
Access 2013
I am not sure. It is likely you were not considering the importance of normalizing the data. If your data structure is good (Normalized) you can focus on importing data. If your data structure is not normalized, you are not going to be able to import data. It usually takes several attempts to normalize your production DB. I will look over the thread to see if I have any other opinions on the matter.Originally Posted by Skibber
Sometimes Helpful
Windows 8 Access 2013
I did a small amount of Googling and it seems that the data may, indeed, be stored within the PLC. It seems DataWorx is a third party service that acts as a server for the data generated/stored by the PLC. Depending on what version of DataWorx you have, you can use its server to provide tab delimited or comma delimited text files. You should be able to import a text file generated by DataWorx directly into a normalized data structure within Access.
Alternatively, you should be able to have Access log data directly from the PLC (whatever that is). If DataWorx can do it, why can't you and Access do it?
Novice
Windows XP Access 2003
I have the communication all set up and DataWorx is feeding info to the DB just fine with the current config. In my attempt to normalize my DB, I wanted to have separate tables for departments and work stations that were referenced in the cycle times table instead of just having those fields populated with data from the PLC. At first I just created a table for each work station that just logged all of the cycle times. I thought that it was not recommended to have redundant fields in multiple tables.
Sometimes Helpful
Windows 8 Access 2013
I think this is your hang-up. Nobody here has mislead you. Use Key fields in your tables to define relations. Every table should have a Primary Key. Store the value of a Primary Key field in the Foreign Key field of a related table.
Whether you have 3 workstations or 50,000, you should have one workstation table. It will have a Primary Key column. This column will consist of fields that uniquely identify each workstation. Additional columns will define attributes for the workstations. For instance, one column may be a business key. A business key is something that Users/Humans understand as a unique identifier (WRK_12). Additional attributes may be associated with a date the workstation first went online. Additional columns may be intuitive to humans or they may be Foreign Key fields. For instance, placing text that describes a workstation's manufacturer in an attribute will not follow rules of normalization. Instead, there would be a separate table for Manufacturers and the Primary Key value from that table would be stored in a Foreign Key field within the Workstations table. Attributes can be a text description as well as a Foreign Key field.
https://www.youtube.com/watch?v=-fQ-bRllhXc
Novice
Windows XP Access 2003
Agreed and thanks for the guidance. Right now I'm focusing on having 1 table to log the cycle times with multiple fields that distinguish where the times came from for a specific entry. The other fields (Dept & Station) would be my foreign keys in that table then...right?
Maybe I don't completely grasp the concept yet or just wasn't correctly explaining what I am looking to achieve.
Sometimes Helpful
Windows 8 Access 2013
So, a table that records events will typically have several Foreign Key columns. In other words, something happens. Maybe a widget is built or a machine is taken offline. So a table may have the sole purpose of logging the production of widgets and another table would record machines being taken offline. If a human is to look at either of these tables, the data within will not be intuitive. There should not be a lot of text that describes a machine being taken offline. Instead, multiple Foreign Key fields will be populated with numbers. These numbers represent records within other tables. These numbers are values that can be referenced in the Primary Key field of the respective Entity's table.
Yes, I think you are doing the correct thing by focusing on a table to record events. And, yes, this table should have a column with a Date/Time. Other columns will be Foreign Keys. When you look at a table that represents entities such as, a workstation, an employee, a manufacturer, etc., these tables will be more intuitive to humans than a table that records events. It is more likely to have attributes as type text in a table for employees than a table that records events.
Posting Permissions
Reply With Quote