Thanks Jamie for the quick feedback. I think your answer has me convinced more than ever there is something performed in the process I'm not understanding (which is why I don't totally understand the suggestion.).
* We are running 7.7.1 at the moment - but an upgrade will occur sometime 1st half this year.
* I get the point of setting up AD groups - so that Only Analysts are processed - that was all clear. I just figured I would see if ANY update worked before doing more setup.
So - yes, I see where I can avoid "the volume of errors" for the normal End Users. But, even the accounts that are for an Analyst fail when I try and run the import. The following is from the Import I setup to test with. It used the exact same Data Connection as the User Import - and in fact I have the same mappings. The only difference is the Target Business Object is the Analyst Object and not the User.
So - I pick one of my users. When I run the user interface he does not get "updated" because of the User Type mismatch. Yet when I run the Analyst update the same ID (and all others) fail with the duplicate key. What I'm missing - no matter what I do - the records for all Users and All Analyst go into the SAME table (TPS_User). What I am looking for is for the import to understand "update vs. Insert" - like it does for the User accounts. Even if somehow I switch the Import Key (I can do that - no issue - and have only Analyst). When I run the 2nd time that Key too will be in the tps_user table - and error. Right?
Sorry for being thick! There is something I'm missing - that allows the User to process as an update (in fact - it is the key that determines Insert (new) vs. Update - if the key matches then update and don't insert.
Is it simply that in order for this to work the Analyst NEVER should have imported as an End User? That still does not make much sense to me - as it is the Analyst import that appears to want to insert into the constrained index.
Terry
