You need to be more precise in telling us what you are doing in each step or we cannot tell for sure. For example, in your Step 2 when you write "Activate the table window and double click a "code" value in a table" You do not say *which* table window of the two tables in your project. Note also there are no fields called "code," just fields called "Code." The first is critical to say, the latter is just to get you into the habit of writing precisely. For example, you could write: "Open the LkUp_tbl table and double-click on the Code cell in the second row, changing it from 2 to 3." My advice is to open the drawing and the labels components in their own windows and zoom out far enough so you can make the windows small enough to fit on your desktop. You can then open the table windows and resize them to have both tables open on your desktop at the same time as your drawing and labels window. To avoid confusion do not use the map and do not mess with selections since they don't have anything to do with the relations but can just confuse you. The main thing that I see in a quick review of your project is how you have formed your relation between the tables, where the LineDrw Table has a column in it, Colour, that is brought in as a relation from LkUp_tbl. That column is brought in by matching the values in the Code column in the LkUp_tbl table to the values in the Code column in the LineDrw Table table. You are bringing in a Colour value via the relation and the key field you are using to do that, that is, to match up what is in the origin table to the destination table, is the Code field that is common to both. Note from the Relations topic in Help: A relation between tables uses a key field with unique values common to both tables
The Code field in both tables is your key field. It must have unique values common to both tables. That means that given the way your tables are set up you really cannot make any changes in the Code column in either table. Consider the third row in the LkUp_tbl table: if you change the Code value in that row from 3 to 2 you violate the constraint that the Code values are unique, because you end up having two records both with a 2 in the Code field. No go. If you change the Code value in that third row from 3 to 4 you satisfy the constraint that the values for the key field, Code, are unique but now the values for Code are no longer common to both tables since the receiving table, the LineDrw Table table, has no record with a value of 4 in the Code field. The above means your step "change a different attribute value(between 1-3) and hit return." ... is an error if you mean the LkUp_tbl table, at least until you edit some other record to restore order. For example, suppose in the LkUp_tbl table you edit the Code value in the third record to change it from 3 to 1. The green line disappears in the LineDrw Table table and also in the drawing because the relation has been broken. Suppose now you edit the first row in the LkUp_tbl table to change the value of Code from 1 to 3. The green line reappears and all is correct because the relation has been re-established. That the above works, ie, that you can break the relation and then Manifold will heal it, is surprising and not to be expected. For example, if you break the relation by changing the Code values in a similar way in the LineDrw Table table and then try to unbreak it, that won't work. I don't know what the business or technical problem is that you are trying to solve by using this approach. If you tell us about that perhaps someone on the forum can suggest alternative approaches, such as using queries. Relations are fine for many things but a situation where people may be interactively editing the key fields used to bring a relation into a table from another are probably not a good use of them given the uniqueness and commonality constraints on the key field in both tables.
|