PDXpert PLM Software
Managing a PDXpert test server
Last update 2022-12-07
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 target 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 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 can be imported into, or used with, one TEST system.
One 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 use the TEST system only for database activities, you may skip copying the library files. For example, physical files are 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're not sure, contact Technical Support.
If you use PDXpert 13.0 or later, you can skip this step. If you're using PDXpert 12.2 or earlier, you must 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 SQL 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.
To adjust the TEST system's workflow emails:
To continue using the production email account to send emails, keep all settings from the production database.
To use a different email account (for example, PDXpert.TEST@MyCompany.com), follow the instructions in the email setup help topic.
To block all emails from the TEST system, edit the SMTP server:
Selectmenu ➔ command.
On the Email Management window, in the Outgoing mail server (SMTP) textbox, enter this SMTP address 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 software license and different DatabaseId, add the following data transformation to both the source and target systems, and run it.
PDXpert 12.2 or earlier: Export-System-Identification.txt
PDXpert 13.0 or later (content 574): Show-System-Identification.txt
This step only needs to be done once: when you move the source database again, the target database will contain the source system's transform.
Each server is responsible for managing and updating its own localhost client. Do not connect one server's localhost client to another server that has a different release. 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.
Connecting PDXpert clients in a mixed-release environment§
Do not connect one server's localhost client to another server that has a different release.
After you've created your test server, you may want to use a different release for upgrade testing or other tasks.
A remote client can connect to servers that are at different releases. The process is managed by the remote client's "launcher" (PDXpert.exe) that first connects to the server. When the PDXpert launcher connects, the server identifies its own release.
- If the PDXpert launcher recognizes the server's release, the launcher immediately runs the matching PDXpert client (PDXpert.UI.exe) release.
- If the server's release is not available on the remote workstation, the server downloads its own PDXpert UI client to the user's workstation, and the user is prompted to install.
The client launcher now has releases that match each server. Next time, the launcher runs whichever UI release matches the server. It can switch between any number of different servers with different releases.
Upgrades work the same way: the launcher connects to the server, the new server downloads the upgraded client
code, and that new release is added to the available PDXpert.UI.exe releases.
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: Client deployment
- 010. Upgrading the PDXpert Application Server
- 011. Upgrading the PDXpert PLM client
- 012. PDXpert server post-install checklist
- 013. Install license CA certificate chain
- 014. Moving PDXpert server database and files
- 015. Managing a PDXpert test server
- 016. PDXpert Application Server diagnostics
- 017. PDXpert PLM client diagnostics
- 018. Microsoft SQL Server diagnostics
- 019. Microsoft SQL Server log files
- 020. Connecting SQL Server Management Studio
- 021. Upgrading SQL Server
- 022. Service configuration settings
- 023. Application folders and files
- 024. System architectural diagram
Release notes (change history)
- 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
- PDXpert 14.0 release notes
- PDXplorer 5.2 release notes
- PDXplorer 6.0 release notes
- PDXpert 15.0 release notes
- PDXplorer 6.1 release notes
- PDXpert 16.0 release notes