Have you tried confirming the ''td'' user password by directly logging into the SQL-Server Management Studio tool from your QC server (ODBC would work in a pinch)?

Just as a test, try doing the same when pointing SQL Management Studio (or ODBC) to the OLD SQL-Server and login as ''td''.

So, it works with the NEW SQL Server but not with the old one.
I am not suprised since our DBA probebly re-purposed the old SQL-Server instance recently.

How would that have anything to do with it? We migrated everything over and it worked.

What I think happened to you is that since in QC the PROJECTS point independently to their corresponding DB (via connect string, DB name and ''td'' user password in the DBID files), they were likely all migrated just fine.
The qcsiteadmin_db was also migrated in the same fashion as the project DB's, but to change how QC points to it, you need to change the connect string in a file called SITEADMIN.XML, then re-deploy QC.

Do you remember doing that?

Look again at the DB Connection String /URL in your SITEADMIN.XML file and compare it to the one in the DBID.XML file for one of you recently working projects. If the one in SITEADMIN.XML is still pointing to the older SQL-Server, there is your problem.

Look here for SITEADMIN.XML to modify [default location]:

C:\Documents and Settings\All Users\Application Data\HP\ALM\application\20qcbin.war\WEB-INF OR

C:\ProgramData\HP\ALM\application\20qcbin.war\WEB-INF

Look in your ''repository'' path for the project DBID.XML file(s) [default location]:

C:\Documents and Settings\All Users\Application Data\HP\ALM\repository\qc OR

C:\ProgramData\HPALM\repository\qc OR

c:\Users\All Users\HP\ALM\repository\qc

OK, that was the discrepancy.

We have made the modification to the DB CONN STR (DB Connection String) in the SITEADMIN.xml file, now what?

Now you re-deploy.
Assuming you are using JBOSS (instead of Weblogic or Websphere),
This is easily done from the Start Menu under HP ALM Platform / Deploy Wizard.

Follow the defaults and allow it to start JBOSS at the end and you should be good to go.

**WAIT...**

**A WORD OF WARNING,** though: Try to get yor DBA to re-migrate the qcsiteadmin_db from your OLD SQL-Server to your NEW one (and re-run the td user fix EXEC commands as before). Have him choose the last backup made from just before he disabled the ''td'' user or SQL instance (probably a few days ago).

Since your QC/ALM instance was still pointing to the OLD SQL-Server instance all along, any new users, project changes (like migrating them to a new SQL server instance), etc. are not in the copy on your NEW SQL-server. I hope they did a backup.

Thank you for your insight.
The DBA does have a backup.
As it turns our they only disabled the ''td'' user on that SQL-Server just the other day and that was when the problem started.

They have notes on the migration process and will complete it (again) soon for our qcsiteadmin_db.
After that, we will re-deploy via the wizard.

What a pain we missed the siteadmin.xml change a few months ago.

All is well now... thanks so much!!!