… and inserting 2000000120:”User”-record will create a 2000000121:”User Property”-record.
I started with the moral of the story. Now I will tell the story.
I had to write an export/import to export/import user info. Exporting went fine but I had problems importing the data.
The “User Security ID” as a primary key instead of the “Windows Security ID” was NOT the problem! It is only annoying not being able to use the primary key to connect the tables, that makes it more fun.
The problem was the error I got on the T2000000121:”User Property” table. The record already existed.
First I thought I was so ‘lucky’ to hit a non-unique GUID (1 chance in a few 1.000.000.000, so I was already thinking to try playing the lotto [chances are way higher to win with the lotto than hitting a non-unique GUID!]).
Checking that out, I noticed it was not the case and I noticed that records where created in 2000000121:”User Property”! But I wasn’t even using INSERT(TRUE)….. And there is no code in the triggers of table 2000000120:”User” either….
That means that some code is hidden and unreachable behind the table-triggers of table 2000000120:”User” that keeps tables 2000000121:”User Property” and 2000000053:”Access Control” up to date.