To populate the references, one must again work from the "N" side. Those are the names by default of the reference fields, you may change them if you prefer more descriptive names. You will see that a N:1 reference field named "Master List" has been created in the "Current Categories" table, and that a 1:N reference field named "Current Categories" has also been created in the "Master List" table. So, in the "Current Categories" table, perform the action "Create table reference" to the "Master List" table. Links are always created from the "N" side. From your description, I understand that several records in the "Current Categories" table must be linked to one record in the "Master List" table, so the "Current Categories" table must include a N:1 reference to the "Master List" table. Fortunately, it is not very difficult to make Ninox initialize its flavor of links from values in an imported table.įirst, the link must be defined. Ninox manages links by some internal mechanism - what I would call "hard links". Suppose we have 1,000 new records uploaded by CSV, it would be logistically impossible to religiously click the button for each of the 1,000 new records.Contrary to some other well-known database systems, Ninox does not manage links depending on the value of some data fields - what I would call "soft links", because changing the value of a data field "automatically" updates the link. Let y := last((select 'Raw PI ID' where 'LINKER 2' = x).Id) Again, this button is on the shipments table: I then created a button trigger (on the shipments table) that when pressed will link the item from the matching records from the shipments table to the PI ID table when clicked. I named this "SKU-PI ID" pairing column into "LINK" (from the Shipments table) and "LINK 2" (from the PI ID table). Next, since I don't want to deal with "and" qualifiers, and since the SKU-PI ID is unique, I can just concatenate both columns into a single array, thereby producing a unique SKU-PI column, reducing the parameter to match into 1 instead of 2. Firstly, since the "PI" on the shipment table can be added with other characters (PI USA, PI CA, etc), it can just be remedied by slicing the PI data into different arrays through their spaces, and then extracting the first word on the array, which would be the root PI ID. Essentially, it's a 1:N, Raw PI ID : Raw Shipment ID table relationship. These PI orders can be split into multiple shipment IDs. PI 1 from the table 'Raw PI ID' can be split into USA and Canada shipments, which when translated on the 'Shipment ID' table becomes, PI 1 USA and PI 1 CA). Now, for the 'Raw PI ID' table, we have a "PI" and the product ID represented by the column "SKU".įor the Shipment ID table, each shipment line item still has a "PI" column (but since the PI can be split into multiple shipments, the PI can change in nomenclature, ie. We can't restructure or combine these two tables as different teams (which work independently) work on each table, so restructuring them would burn more time than we can save. We work with both our distributor side and supplier side, that's why we have 2 tables PI- being the orders on our supplier side, and Shipments on our distributor side. So, we have 2 tables - Raw Shipment ID and Raw PI ID. Hi I'm sorry, I was making this post in a hurry.
0 Comments
Leave a Reply. |