PDXpert PLM Software
Managing a PDXpert test server
Last update 2019-11-20
You may want to copy PDXpert production data to a different computer for report development, import testing, upgrade verification, user training, or other non-production purpose.
In this topic, the source computer contains an existing database and library files that is copied to the target (or TEST) computer.
The source and target systems cannot contain duplicate software license keys or database unique identifiers. The TEST system must be adjusted before it can be used alongside the production system.
Your PDXpert software license agreement requires a separate license key for each PDXpert server. The source and target servers must use different license keys.
PDXpert client applications use the database unique identifier (DatabaseId) to cache data for each database separately.
When more than one system shares the same DatabaseId, the PDXpert client cache may be corrupted when switching between the two systems. This can damage the production database or cause client connection errors.
Moving a production backup into a test system§
All PDXpert clients must be logged out of the target system before you begin.
Do not allow PDXpert clients to use the target (TEST) system until these steps are done.
To use configure the target system:
Obtain a TEST server license key for the target server.
The TEST system license can be used only for test, training and development purposes. It cannot be used for a second production system. It cannot be imported into, or used with, more than one TEST system.
The TEST key is available on request if you have a license with a current maintenance subscription. The TEST key expires at the end of the subscription period, and must be renewed.
Copy the production database and library to the target server as described in Moving your PDXpert PLM database and file library. Do not perform the final Uninstalling the source server section.
If you're using the TEST system only for database activities, you may skip copying the library files. For example, physical files may not needed for report development, user role & change workflow tests, and bulk import/update tests. However, some functions may not work, such as (obviously) viewing/copying files, exporting PDX packages, and bulk updates to file attachments.
If you use PDXpert 13.0 or later, you can skip this step.
Update the TEST system's DatabaseId so each client uses a separate cache for the source and target systems.
Using SQL Server Management Studio, Powershell or other tool, run this query:
UPDATE dbo.PDXpertInfo SET DatabaseId=newid();
Restart the TEST server machine, or use the Windows Control panel to restart the PDXpert Server service.
As an administrator, open a PDXpert client:
Log into the TEST system using the target server computer's machine name or IP address.
The TEST system normally contains the same user accounts and passwords as the production system. If the test license allows fewer user accounts than the production system, you must log in using the super administrator's account, which may require you to reset the administrator password.
If you don't want TEST system to send email notices from the production email account, edit the account information:
Selectmenu → command.
On the Email Management window, do one of the following:
- Enable the TEST system email account by setting the account, SMTP server, etc.
- Disable all emails: in the Outgoing mail server (SMTP) textbox, enter an invalid SMTP address, like: smtp.example.com
Close the Email Management... window.
At your option, set the TEST system's color code.
To confirm that the production server and test server have the correct DatabaseId and software license values, add the following data transformation to both systems.
PDXpert 12.2 or earlier: Export-System-Identification.txt
PDXpert 13.0 or later: Show-System-Identification.txt
Each server is responsible for managing and updating its own localhost client. Do not connect one server's localhost client to the other server. Do not install another PDXpert client on the TEST server. Remote clients — that is, clients that connect to a named server rather than to localhost — can freely connect to either server, which can be different releases.
Before installing a new PDXpert release or SQL Server upgrade on the production system, you can upgrade the TEST system to verify correct operation. In most other cases, use the same PDXpert release and SQL Server version on both TEST and production systems.
Consider taking a backup now. Restore this backup when you wish to return to the starting test configuration, without repeating the steps above.
Install Guide Contents
- 001. Installation overview
- 002. Preparing the server computer
- 003. Standard PDXpert System setup
- 004. Standard PDXpert PLM client setup
- 005. Installing LocalDB for PDXpert client ODBC
- 006. Custom installation: SQL Server
- 007. Custom installation: PDXpert server
- 008. Custom installation: Private cloud
- 009. Custom installation: Group Policy
- 010. Upgrading the PDXpert Application Server
- 011. Upgrading the PDXpert PLM client
- 012. PDXpert server post-install checklist
- 013. Moving PDXpert server database and files
- 014. Managing a PDXpert test server
- 015. PDXpert Application Server diagnostics
- 016. PDXpert PLM client diagnostics
- 017. Microsoft SQL Server diagnostics
- 018. Microsoft SQL Server log files
- 019. Connecting SQL Server Management Studio
- 020. Upgrading SQL Server
- Installing and upgrading older PDXpert releases
- 024. Service configuration settings
- 025. Application folders and files
- 026. System architectural diagram
Release notes (change history)
- PDXpert 10.0 release notes
- PDXpert 10.1 release notes
- PDXpert 10.2 release notes
- PDXpert 10.3 release notes
- PDXpert 11.0 release notes
- PDXpert 11.1 release notes
- PDXpert 11.2 release notes
- PDXpert 12.0 release notes
- PDXpert 12.1 release notes
- PDXpert 12.2 release notes
- PDXplorer 5.0 release notes
- PDXplorer 5.1 release notes
- PDXpert 13.0 release notes