Error: “Compile error in hidden module: CTDServers” when using the Excel macro

When using the Excel macro to export data into a TestDirector project, the following error message appears:

"Compile error in hidden module: CTDServers."

The macro may not have been started properly or the appropriate library is not being used.

This can happen for TestDirector or TestDirector for Quality Center.

Possible solutions:

1.. a. Open Excel.

b. Go to File -> Open.

c. Open your "Program Files\Microsoft Office\Office1x\XLStart\TDExcelAddin.xla" file.

2. Make sure that OTA COM Type Library is selected:

a. Within Excel, Go to Tools -> Macro -> Visual Basic Editor.

b. Select VBAProject TDExcelAddin.xla (highlight). (please contact Mercury Interactive support for the default password)

c. Go to Tools -> References.

d. Scroll down to OTA COM Type Library, move it up in the list and make sure it is selected.

3. Re-install the Excel Macro.

a. Select Start -> Settings -> Add/Remove Programs.

b. Select "TestDirector Microsoft Excel Add-in" to un-install the Excel Macro.

c. Download and re-install the Excel Macro from the TestDirector Add-in page.

4. Get the TDExcelAddin.xla file from a working machine and replace that of the affected machine. TDExcelAddin.xla is located at "C:\Program Files\Microsoft Office\OFFICE1x\XLStart".

Run the HP Quality Center Connectivity Add-in which provides the ota objects necessary for excell addinFixed the paths and OTA COM type Library version

Note : If none of the suggested solutions works, get the C:\Program Files\Microsoft Office\OFFICE11\XLStart\TDExcelAddin.xla file from a working machine and replace that of the affected machine.

For later versions of ALM please use the HP Quality Center Connectivity Add In available from the Add-ins page.

How to move defects from one database to another

Copy and paste defects from one project to another

In order to move defects from one TestDirector / Quality Center database to another, you can use the "Copy" and "Paste" functions to copy and paste defects from one instance of TestDirector to another instance of TestDirector.

1. Open one instance of TestDirector and connect to db1.

2. Open another instance of TestDirector and connect to db2.

3. With both databases opened, go back to the TestDirector instance with db1 and select the records from the grid that you want to copy. You can create a filter for the defects you want to copy. Right-click and choose "Select All" or go to Edit -> Select All.

4. Click on the Copy icon or go to Edit -> Copy.

5. Switch to the other instance of TestDirector with db2 and click on the Track Defects tab.

6. Click on the Paste icon or go to Edit -> Paste.


When copying defects, the Defect IDs are not copied. This is because these ID numbers are managed by TestDirector / Quality Center to maintain uniqueness.

The field type and field length of the corresponding fields in both projects should match in order to copy the data over. For more information, please consult your TestDirector / Quality Center administrator and the Open Test Architecture guide. For Quality Center 9.0, refer to the Mercury Quality Center Database Reference found in Quality Center under Help -> Documentation Library.

Additionally please note that this will only work if both projects have the same customization.

Upgrade a Quality Center 10 project to Quality Center 11 on a new Microsof SQL Database server

The following steps show one method to upgrade Quality Center (QC) 10 to QC 11

1. Deactivate the project in version 10.

(NB: If this is a version control project ensure all checked out entities have been checked in before taking a backup of the project)

2. Make a DB backup of the QC project schema.

3. Make a backup of the QC 10 project folder from the repository on the file system.

4. Create a new project in QC 11 and name it the same way as the desired restored project name.

5. Remove the newly created project from QC 11. (DO NOT DELETE IT)

6. Restore the DB backup of the QC 10 project schema in the new DB server on the schema that was created when the new QC 11 project was created and restore project repository to the new location.

7. Link the td user with the td login by executing the below SQL query on the restored project schema in the DB server:

EXEC sp_change_users_login ‘update_one’, ‘td’, ‘td’

exec sp_change_users_login ‘report’

8. Edit the dbid.xml file. There is only 1 entry that needs to be edited from Y to N, please check below:




9. Delete the folder called "ProjRep" and leave just the already edited dbid.xml file.

10. Restore the project from Site Administrator.

11. Run the Verify tool.

12. Run the Repair tool if needed.

13. Upgrade the project.

14. Activate the project.

15. Login in order to verify if everything is ok.

Duplicate Favorites Issue when upgrading a project from QC 10.00 or earlier to ALM 11.00 and versions above

In Application Lifecycle Management (ALM) 11 if you get the below error :

[SQLServer JDBC Driver][SQLServer]The CREATE UNIQUE INDEX statement terminated because a duplicate key was found for the object name ‘td.FAVORITES’ and the index name ‘FAVORITES_NAME_LWR_UK’. The duplicate key value …

The reason for this error is because , in Quality Center (QC) 10.00 and earlier versions of QC it was possible to have different kind of favorite filters (for Grid and Tree views) with the same name.

In ALM 11.00 and above the favorites were consolidated to the ‘Favorites’ menu in both of the views (Tree and Grid Views). Duplicate names are also not allowed in later versions. This is causing the upgrade error in ALM 11.

There is no fix available for this issue now. Until a fix will be implemented the following workaround for the project can be applied

1. Run the following query:




and a.CSET_NAME <> ‘__default__’

and b.CSET_NAME <> ‘__default__’

and a.CSET_OWNER <> ‘__default__’

and b.CSET_OWNER <> ‘__default__’




order by a.CSET_NAME

2. For each row (CSET_NAME, CSET_OWNER) pair in the result run the following query:




Replace the <CSET_NAME> with the row CSET_NAME value from the result of query 1, and <CSET_OWNER> with the row CSET_OWNER value from the result of query 1.

The ALM server gets muted and the error shown is “ORA-28001: the password has expired”

The Application Lifecycle Management (ALM) server could enter a “Muted” state when trying to access the main qcbin page. The error that is received in that particular scenario is the below:

ERROR: ORA-28001: the password has expired

The above ALM error is related to the Oracle server. The root cause behind this issue is that the password for the qcsiteadmin_db user has expired.

The easiest way to deal with the situation and revert back to normal ALM operation is to change the password of the qcsiteadmin_db back to what it was. Typically there is a default password being used by ALM.

Here are the steps that should be followed:

1. The below command will change the password of the Oracle user from sqlplus:

alter user <USERNAME> identified by <password >

2. Then a restart of the ALM service is needed.

How to execute, enable, disable, and hide a button using the VBScript Workflow

The Actions command can be used to execute, enable, disable, and hide a button. The following example demonstrates how to disable and hide the R&D Comments button as well as the corresponding R&D Comment view upon entering the Defect module.





Actions.Action("BugAddDevCommentsAction1").Enabled = true


If there is a corresponding menu option, you should check it also:

Actions.Action("_dxact_main_menu_menu_rdcomments").Checked = true


Actions.Action("BugAddDevCommentsAction1").Enabled = false


If there is a corresponding menu option, you should uncheck it also:

Actions.Action("_dxact_main_menu_menu_rdcomments").Checked = false


Actions.Action("BugAddDevCommentsAction1").Visible = false


Sub Defects_EnterModule

On Error Resume Next

Actions.Action("BugAddDevCommentsAction1").Enabled = false

Actions.Action("BugAddDevCommentsAction1").Visible = false

Actions.Action("_dxact_main_menu_menu_rdcomments").Visible = false

On Error GoTo 0

End Sub


The "RPC_E_SERVERFAULT" error results when an application that uses the OTA instantiates many of the same objects by a single user or by multiple users. This may be multiple TDConnection objects or many Command objects.

This can occur in any application written in a language which supports COM such as any of the languages offered in Visual Studio.

The "RPC_E_SERVERFAULT" error most commonly occurs when the QC/ALM OTA API is used in a Web Application or Web Service because many users access these application where multiple objects are instantiated by different users accessing the Web Service or Web Application.

The error "RPC_E_SERVERFAULT", in respect to the OTA API, is caused by too many objects being instantiated from the same OTAClient.dll reference. It is an overload of the API.

More information is available here:

The error is also common in applications which make liberal use of the "Command" object. Use of the "Command" object is highly discouraged as the QC/ALM Client does not use the "Command" object. It is suggested that standard OTA objects be used instead. Use of the "Command" object is provided only for situations where regular OTA objects can’t accomplish the task. That said, multiple instances of the same object, not just the "Command" object, can result in the "RPC_E_SERVERFAULT" error.

It is important to mention that the QC/ALM OTA API uses the WinINet API. The Microsoft Windows Internet (WinINet) application programming interface (API) enables single user applications to access standard Internet protocols, such as FTP and HTTP. WinINet does not support server implementations. Because the OTA API uses WinINet it should not be used in Web Service or Web Application solutions. For server implementations or services Microsoft recommends use of WinHTTP.

Although WinHTTP API is effective when using APIs in a Web Service or Web Application is is a completely different framework than WinInet. For more information see ‘WinInet vs WinHTTP’:

There are no plans to implement WinHTTP with the QC/ALM OTA API.

When implementing the functionality of ALM as a Web Service or Web Application the OTA API should be avoided as it is a single user, single threaded API (due to its use of the WinInet API).

In ALM the REST API was selected over implementing WinHTTP. The REST API offers platform independence while maintaining the existing OTA API in its current form.

The ALM REST API is recommended when implementing the functionality of ALM as a Web Service or Web Application or in applications where platform independence is an objective.