SOLIDWORKS PDM Database Modifications

If you know anything about SOLIDWORKS PDM, you know its two major components are comprised of an archive server and a database server. The database server is powered by Microsoft SQL. Each vault has a database in SQL that houses just about everything you see in a vault that isn’t the actual files themselves. Everything from your data cards and workflows to user information and licensing is stored in SQL. This is invaluable data - and it should be approached with caution if you want to preserve the integrity of your vault infrastructure.

There are times when you will need to edit your SQL database; these are specific use cases where your VAR (or Dassault Systèmes) will advise you to do so and specify exactly what needs to be done. Examples of approved database editing would include migrating your PDM to a new server or restoring a deleted user (pre-2023). When these edits are made, you’ll also want to ensure you are taking backups beforehand. Even small changes can go awry, and you never want to risk making them without a point to restore to.

You should never edit your database unless your VAR or Dassault Systèmes advises you to do so.

Why is this Important?

A lot of this might sound overly cautious – and I promise we’re not trying to induce any unnecessary fear. Let’s talk a little bit more about why this matters.

You’ll see the “unsupported” label thrown around a lot when discussing SOLIDWORKS and PDM. It doesn’t mean the same thing in every context, however. There are many levels of “unsupported” in a PDM environment. They’ll usually fall into a few major severity levels:

1. Not fully tested/validated, but generally still very workable and stable.
2. This might work now, but we can’t guarantee stability or long-term reliability.
3. This probably will not work as expected (or at all).
4. This should not be considered and will almost certainly harm your environment.

Something like database modification immediately falls into level 4 due to the backend makeup of a vault database.

Hosting your vault on a cloud server, however, is also technically unsupported. Yet GoEngineer offers a cloud-hosting service for PDM vaults that we stand behind as a great solution for accessibility and reliability. This would be an example of a “level 1” severity.

Dassault Systèmes labeling something as unsupported can be as simple as an inability to fully test an environment (cloud hosting is an example of that). There are thousands of cloud environments and configurations customers could use, and they’re constantly changing as new technology and security changes are made. There’s no way Dassault Systèmes could feasibly validate these setups, but we know from experience that cloud servers are very stable and work seamlessly with PDM. We wouldn’t offer these services if we didn’t believe that!

It should be noted that being deemed unsupported – regardless of which “level” - means we are unable to assist with issues that may arise unless those issues can also be reproduced in a supported (and un-modified) environment.

Infrastructure

A database can be roughly imagined as a very large, multi-sheet Excel workbook. Each vault database is comprised of over 200 tables.

Each table is comprised of a set of rows and columns containing data about your vault. Many of the tables use identifiers that link them to other tables, which PDM uses to display and modify the files and data you see on the front end.

This isn’t static data, however. Adding a new file to your vault isn’t as simple as inserting a new row with the file name. There are complex back-end hooks and stored procedures spanning between multiple tables and fields that rely on specific actions performed in a specific order for them to reliably trigger. Just adding a single file to PDM can reference or modify upwards of 20 different tables in the database.

PDM’s database is a live system that’s constantly changing, being accessed, and balancing to give you the files and functions you see on the front end. Destabilizing that process could have disastrous results.

If you go in and change fields that rely on particular triggers, the expected processes may not be able to run the way they’re supposed to. And the worst part is, that some of these changes may not be immediately obvious – the time it takes for issues to become apparent can vary depending on what was changed. We’ve seen clients discover previous administrators manual edits years later, and it was a nightmare to unravel once found.

Which leads us to…

Potential Consequences

There are core functions of PDM that are assumed to work in a specific way, like what was covered on the infrastructure of a database. These core assumptions are how we navigate PDM. It’s how we can infer expected behavior (and when we’re not seeing that), and it allows us to effectively troubleshoot your issues and provide guidance on how to interact with your system.

If the infrastructure of PDM is altered, we can no longer trust these core assumptions, and suddenly our ability to reliably investigate and identify your issues flies out the window. By making modifications to your PDM’s database, you’ve essentially voided the warranty for your vault. Car manufacturers often state that after-market modifications void the warranty and prevent them from offering support for your car because they have no control or insight into how these aftermarket parts could interact with the vehicle’s expected function. Technical Support teams work much the same way.

Both Dassault’s and GoEngineer’s Support teams are unable to assist if issues arise as a result of unauthorized database edits. Once those changes have been made, the only path forward is to restore the database to a point prior to those edits being made. We cannot reliably troubleshoot a system that has been modified in a way that could alter its core behaviors.

Here’s a (non-exhaustive) list of some of the things we’ve encountered as a result of database modification. Since you could potentially edit the database in an infinite number of ways, the type and severity of consequences can vary significantly.

• Being unable to upgrade PDM until the modifications were removed.
• Excessive load on vault performance, leading to lag and instability.
• Data being corrupted and incomplete.
• Data going missing entirely.
• Being unable to create, modify, or delete workflows/states.
• Files being moved to states that don’t actually exist and getting stuck there.
• User permissions not being applied properly and allowing users to see things they shouldn’t (or not see things they should).
• Missing values in data cards.
• Users being unable to log in or connect to servers.

Conclusion

Some of these situations could be resolved, while others had to be worked around. In every case, our hands were tied in how much we could assist. Taking the chance to make changes in your database outside of those recommended by your VAR is never worth the risk.

You are always welcome to run read-only or “select statement” queries against your database – it’s your data, after all! You can gain some very useful insights and report outputs by utilizing the vault’s database directly. Dassault Systèmes even publishes many premade queries for customers in the 3DSupport Knowledge Base.

If you need to make changes to the vault in ways you can’t accomplish using the front-end user interface, there’s still a safe way to do it! PDM Professional has an API you can utilize for exactly this purpose. It’s a safe and supported way of programmatically altering data in your vault. We’ve published some helpful information about the SOLIDWORKS and PDM API if you’re interested in learning more!

If you ever come across a situation where you suspect the database might need modifications and you’re unsure whether this is something you can do safely (and GoEngineer is your VAR), contact our Technical Support team.

GoEngineer's Support Team has years of experience with SOLIDWORKS PDM and its inner functions and can help you determine whether this is a safe change (and what other options you may have if it’s not). We can also provide resources and guidance to help you make a change in the safest and most bomb-proof way possible! In the end, our primary goal is to help you get the software working for your needs and to keep your environment running as smoothly and efficiently as possible.

Related Articles

SOLIDWORKS PDM How to Delete User Accounts

Managing Local Cache in SOLIDWORKS PDM

Controlling Access to Versions and Revisions in SOLIDWORKS PDM

Link SOLIDWORKS File Custom Properties to Variables in PDM

SOLIDWORKS PDM Network Communication Troubleshooting

VIEW ALL SOLIDWORKS PDM ARTICLES