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

Gurus,

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!

Parents
  • Hi Dave,

    strange ...

    The script looks good - there are no transactions in it - so you don't have to "commit" any transactions.

    And if there would appear any errors during the saving of the objects you would get an information on the "error counter".

    So I think the objects were created in the database - the question is: In WHICH database?

    The job "DataImport" (which executes the script for the import) contains the parameter "ConnectionString".

    On this parameter the target database for the import is defined.

    Normally the parameter contains:

    Value = VID_GetValueOfDialogdatabases("ConnectionString")

    ... that means the connectionstring comes from the table "DialogDatabase", column "ConnectionString".

    I suggest to check this parameter in the import job - and if it contains the mentioned default value you should check the value in "DialogDatabase.ConnectionString".

    Maybe your import affected another db...

    No other idea currently.

    Regards,

    Steffen

Reply
  • Hi Dave,

    strange ...

    The script looks good - there are no transactions in it - so you don't have to "commit" any transactions.

    And if there would appear any errors during the saving of the objects you would get an information on the "error counter".

    So I think the objects were created in the database - the question is: In WHICH database?

    The job "DataImport" (which executes the script for the import) contains the parameter "ConnectionString".

    On this parameter the target database for the import is defined.

    Normally the parameter contains:

    Value = VID_GetValueOfDialogdatabases("ConnectionString")

    ... that means the connectionstring comes from the table "DialogDatabase", column "ConnectionString".

    I suggest to check this parameter in the import job - and if it contains the mentioned default value you should check the value in "DialogDatabase.ConnectionString".

    Maybe your import affected another db...

    No other idea currently.

    Regards,

    Steffen

Children
No Data