Skip to main content
R
RT_1139706110-Marble
10-Marble
June 5, 2025
Solved

Windchill Object/File in the Database and Vault

  • June 5, 2025
  • 1 reply
  • 602 views

Hello,
Below question is typical for the beginner level of the Windchill User.
So, I have split my question in three parts,

  1. When a object/file is checked out the on Windchill, is the object checked out from Vault or the database in the realtime?
  2. If the object/file is checked in and checked out several times, are the iterations created on the database as well as vault?
  3. Does Windchill Vault and Database have the same set of objects/files at same point of time? I mean at 10AM in the morning, Vault has 5000 files/objects and will database will have the same set of files at 10 AM?

 

Thanks In Advance.

Best answer by d_graham

@RT_11397061 

 

Nothing ever gets "checkout" from the file vault.  It gets downloaded or uploaded that's it.

Checkout is a database thing not a content file thing.

 

1. You can checkout an object out without downloading it's content.  The database checkout occurs when the user does the checkout. It's as simple as that.  When else would it happen? 10 minutes later?  I don't think so.

 

2. If you checkout and checkin but do not upload data upon checkin the new iteration will point to the existing content file.

So, you could have many iterations pointing to the same content file.

Windchill wants to be efficient. Why upload content files that have not changed?  You wouldn't and neither does Windchill.

 

3. See number 2.  There's no reason to think the number of new iterations in the dB would match the number of new files in the vault.

The number of files in the vault will always be less than or equal to the number of iterations, never greater.

If you delete iteration you need to run remove unreferenced files to ensure my previous statement holds true because deleting an iteration does not also delete the content file.

 

Makes sense?

 

 

 

 

 

 

1 reply

D
18-Opal
d_graham18-OpalAnswer
18-Opal
June 5, 2025

@RT_11397061 

 

Nothing ever gets "checkout" from the file vault.  It gets downloaded or uploaded that's it.

Checkout is a database thing not a content file thing.

 

1. You can checkout an object out without downloading it's content.  The database checkout occurs when the user does the checkout. It's as simple as that.  When else would it happen? 10 minutes later?  I don't think so.

 

2. If you checkout and checkin but do not upload data upon checkin the new iteration will point to the existing content file.

So, you could have many iterations pointing to the same content file.

Windchill wants to be efficient. Why upload content files that have not changed?  You wouldn't and neither does Windchill.

 

3. See number 2.  There's no reason to think the number of new iterations in the dB would match the number of new files in the vault.

The number of files in the vault will always be less than or equal to the number of iterations, never greater.

If you delete iteration you need to run remove unreferenced files to ensure my previous statement holds true because deleting an iteration does not also delete the content file.

 

Makes sense?

 

 

 

 

 

 

    R
    RT_1139706110-MarbleAuthor
    10-Marble
    June 16, 2025

    Hello,
    Thank you for the details.

    Can you help me with this additional question, In case of CAD drawing when its modified and uploaded to Windchill, is the CAD drawing stored in the vault or in the database ?

    M
    mmeadows-316-Pearl
    16-Pearl
    June 16, 2025

    That depends...

     

    If your external file vaults are configured, working, and not marked as read-only, then the drawing and all other content files are stored in the next to last file vault folder.

     

    If external file vaults were not configured or are set to read-only, then the content files are stored in the StreamData table in the database.

    DB Tables relationships: https://www.ptc.com/en/support/article/CS121641

    Cleaning up StreamData: https://www.ptc.com/en/support/article/CS37197

     

    Terms & ConditionsAccessibility statement