This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Designer - SQL Database Import not Updating UNSAccountB


I eluded to this question in a previous post and despite my best efforts, I can't find a solution yet. So here is the situation, one of the applications we are attesting to runs off an MS SQL Database and our DBAs have basically given the Quest account rights to run a few stored processes so that it can synch the users/groups from the SQL application to Quest. The script basically opens a connection string to the database, runs the stored procs and uses the data to populate users (one script) and populate data base roles (other script) into UNSAccountB and UNSGroupB respectively while tagging XProxyContext to be the application name... lets call it DBApp1 for privacy.

In the Production environment, the sccripts work just fine... they pull the data in and populate accordingly. I used the Database Transport tool to import all Change Labels into the Test lab. After verifying that AD synch was working Dev and then making sure that Manager > Unified Namespace has an entry for DBApp1, I ran the import. I watched the job logs intently - refreshing every few seconds, just to make sure everything worked. Yay! The script completed and I got NO errors. I even have the script writing a log file to show me what it does. The log file shows several new inserts into the database. Yay!

THEN... I checked UNSAccountB and UNSGroupB. NOTHING is there... There are no records at all...

I tried the same process again with DBApp2. Again, all things look great! Imports run and NOTHING in UNSAccountB or UNSGroupB. What the heck happened? Where did this stuff go? If the logs think everything is fine and the database is sending data (I verified this). Why doesn't it populate into Quest? Can anyone provide me some insight?

Thanks in advance!

  • Sorry Carsten, I don't follow what you mean exactly.

    Obviously the entries aren't actually DBApp2/Users and DBApp2/Groups. If the name of the application was... say... SAP then the entries would be SAP/Users and SAP/Groups

    What we are doing in the UNSContainerB is basically making a new UNS Location to hold all DBApp2 Entitlements.

    What are you asking?

  • I just wanted to show you that this can't work. The UID_UNSContainerB attribute in UNSAccountB and UNSGroupB is the foreign key to the UNSContainerB table, so it should carry the UID (the primary key) of the UNSContainerB instead of its canonical name. But you can use the canonical name to determine the correct UID by doing a connection.getsingleproperty.

    You know what i mean?

  • I think I follow you but it doesn't really help the situation.

    The reason that you see a Canonical Name as the value for UID_UNSContainerB is because of how we are using UNSContainerB.

    So, DBApp2 has several entitlement groups. A person may be part of Group1 and have RightA. And someone else can be in Group1 but have RightB. So the wawy that the code was written was to look for the / character in a string when importing. So if it sees G1/RightA and then G1/RightB it would create a container called G1 and then make subcontainers RightA and RightB.

    Make sense?

    If this sounds wrong, I hate to say but it is working properly in PRD with the same exact code...

  • And the UIDs are that way in your affected environment as well for sure?

    /edit: updated posting

  • Dave

    could you post the result of the following statement from both of your environments (the working and the non-working):

    select UID_UNSContainerB from UNSContainerB where XProxyContext = '<your XProxyContext>'

    I'd just want to see how your UIDs are looking like....



    /edit: updated posting

  • Dave

    Steffen and i were just brainstorming over your code and we did came up with two things we would need in order to help you solve the mystery:

    1. Could you add a debug line after this line of code in the UNSAccountB import script:

    Line to look for:

    resUID_UNSContainerB = DbVal.ConvertTo(Of String)(columnUID_UNSContainerB.ResolveValue(valUID_UNSContainerB), lineProvider.Culture)

    Line to add after:

    VID_Write2Log(logFile,String.Format("Debug: UID_UNSContainerB is: {0}",resUID_UNSContainerB))

    2. Could you post the result (sanitized if necessary) of the following statement:

    Select UID_UNSContainerB, CN, DistinguishedName, XProxyContext where XProxyContext = '<your XProxyContext>'

    3. Could you attach your import log file (sanitized) for incl. the debug output?



  • I can add this line to the code if needed but before I do so, it should be noted that the particular entry you mentioned is commented out in the code. It appears to have been replaced by this line:

    resUID_UNSAccountB = Connection.GetSingleProperty("UNSAccountB","UID_UNSAccountB", _

      f.AndRelation(f.Comparison("accountname",valUID_UNSAccountB,ValType.String), _

    f.Comparison("xproxycontext", "DBApp2", ValType.String)))

    resUID_UNSGroupB = DbVal.ConvertTo(Of String)(columnUID_UNSGroupB.ResolveValue(valUID_UNSGroupB), lineProvider.Culture)

    Would you like me to add the line AFTER this entry or before it?

  • So just to make sure we're all on the same page: the script line

    resUID_UNSContainerB = DbVal.ConvertTo(Of String)(columnUID_UNSContainerB.ResolveValue(valUID_UNSContainerB), lineProvider.Culture)

    in your user creation script and the group creation script is commented out?

    Can you confirm that for both environments, the working and the none working one?

  • Okay, I apologize for the confusion. This string is NOT commented out in the USER import or the GROUP import script. It is ONLY commented out in the UNSAccountBInUNSGroupB script. Would you like me to add the debug line after the entry on those two scripts?

  • Yes, please add it after the code, run the import and upload your (sanitized) log.