First time post, not sure if this is the correct approach, but I don't know who to contact.
There's nothing like turning the uninitiated loose to find bugs....
I'm new to the mapping manager, so I am completing the tutorial (version 2.03, April 20, 2012). I'm using mapping manager version 2.1.3 build 27 on a Windows 7 Ultimate machine connected to a remote TD 14 1TB VM.
The tutorial section discusses auto-find potential mappings. I created the potential set using auto find. The tutorial wants us to accept all the mappings except for 9 of them and lists the line numbers of those not to be accepted.
Issue 1: the tutorial recommends multiple ways of excluding the line. One method is to select the entire set and ctrl-click those that are not going to be accepted. ctrl-click did not de-select the lines.
I selected lines 1-47 (48 was the first excluded line) and accepted those by right-click->save mappings w/o note.
In my infinite wisdom and laziness, I then decided that the best way to finish was to click the entire set, accept them and then "unaccept" them.
Issue 2: when I selected the entire set and then right-click->save mappings w/o note, I got a unique secondary index violation error code 2803.
The SQL: INSERT INTO MAP_GRP (MAP_GRP_ID, DATA_REP_ID, OWNR_PROJ_ID, MAP_GRP_NM) Values (6,1000,1002,1000,'1'); I can't find any way to fix this error w/o manually deleting rows. Unfortunately, I don't understand the relationships, so I don't want to guess and hose my tutorial. Any help would be appreciated.
Regarding your unselect issue, you need to CTRL+Click in the "data area" of the grid and not on the row numbers. This will only unselect the cel(s) on which you CTRL+Click, leaving the rest of that row highlighted, but functionally the row has been unselected. It is not the best GUI implementation of unselecting a row so I will capture this as a future usability enhancement request.
The USI uniqueness error is a known issue with TMM 2.1.3, when saving mappings without map notes. This has been fixed in TMM 2.1.4. The workaround for TMM 2.1.3 is no always use "save with map note" operations and never use the preference to save without map note prompt.
I do not think your metadata has been corrupted, at least it was not for my testing - but no guarantees as it is a code bug. If you do not want to download the latest TMM and start the tutorial over, I suggest you select all mappings in the auto-match results window, CTRL+Click to unselect the rows mentioned in the tutorial, right-click-> save WITH map note, press Create without typing a map note, then go to map set window and make sure no extra rows were saved on your previous save operation. If so, select the rows that you were not supposed to save and press Delete, Yes to delete them.
No matter what I do, I cannot process the mappings from the auto find. When I re-run the auto find and try to process the rows (with the don't display mapped rows option checked), I keep getting the secondary index violation. Did you run across the same?
BTW, and not that this matters all that much, I'm a former TD employee. I have a couple of potential modeling customers where TMM would be a good fit. However, it would be nice to be able to diagnose and quickly repair any data issues. Any chance you can publish an ER diagram of the data model with relationships?
If you are still using TMM 2.1.3 and saving mapping without map notes, that is the known bug so the USI error is expected. If you are saving with map notes and still getting USI error, then you have apparently found another situation that triggers the same bug. If you cannot finish the training with my earlier suggestions then I can only recommend that you upgrade to the latest TMM version (2.1.4 as of today) which should fix the USI-error bug.
Regarding data models, I am not able to share the ER diagram of the metadata repository for a number of reasons. One of the most important reasons is that we do not want to imply that we support any direct access of TMM metadata tables and, even more importantly, we cannot support or encourage any direct modification of metadata in the repository. If anyone were to directly modify the metadata table contents, there is a good chance that they would corrupt the metadata such that TMM would not be able to use the metadata. BTW, some of the table and column comments are out of date or just plain wrong, so you cannot count on those for proper metadata definition.
If a TMM bug corrupts the metadata repository (I can only recall one case where this actually happened), and it is something other than the training repository, then post your problem and if I am still the product owner for TMM I will try to recover your metadata and get you running again. Teradata cannot guarantee that this will happen, but that is my recommended remediation path if you have a real corruption problem.
We do provide a published set of TD Views of the repository that anyone can use to read the metadata, as documented in the TMM in-app help system. It is believed that the table/column comments for those published views and the associated help topics are accurate definitions of the metadata.