I am conducting a dB restore get an error for not sufficient disk space. The file size report in the error is astronomically larger than the size reported with windows file explorer. What could be causing this?
Hi Bobby -
Without seeing your setup, I can't give you a definitive answer - you really should engage your VAR.
But, the general rule is this. Anytime the modify date is changed on a file, on checkin a new version is created and stored in the archive server. Now, sometimes new version are created in the context of the Workflow. For example, a transition write a variable value to the datacard, which is mapped to the file. This results in a new version in the archive.
A change to a datacard that is not mapped to a file still results in a new version, but, not a new version of the file in the archive.
These change do add records to the database.
So, there are two areas you look at to determine growth: 1) database growth and 2) archive growth (which will be much bigger)
So, one more time - contact your VAR for assistance :-)
p.s. there have been a lot of improvements made in SW PDM. Some of the techniques used in workflows to achieve certain outcomes are no longer required and can be greatly simplified.
I would advise you to open a support request with your VAR.
However, if you choose to proceed (on a NON-PRODUCTION COMPUTER), run the command:
RESTORE FILELISTONLY FROM DISK = 'C:\pathtobackup\backupname.bak';
This will give you information of the file sizes.
You need to figure out the why first. It may be that your transaction log is huge.
If that is the case and you don't want to risk data loss, you need to correct that at the source (e.g. shrink the log file to something reasonable), take another full backup, and restore that. (Then, I would recommend setting the Recovery Model to simple.)
Again - start with your VAR or internal DBA if you have one.
I am working with a DBA. All work is being conducted in a quarantined test environment. I will share your post with the DBA and we will proceed from there.
Okay let him know that, unless he changed it, the default Recovery model is Full.
This means that the transaction log needs to be maintained.
If that is the case, once he deals with that, he change change it to Simple if desired.
I shared this with our Global PDM administrator in Europe. He has contacted the VAR where our licenses are purchased and this has turned out to be good advice.
I have another question? Our EPDM flow process was set up by an outside contractor. Our process creates a new version for every activity and not necessarily on adding value to CAD files. We can have a dozen versions or more for each drawing change. Could this activity create a larger file structure than reported in windows file explorer?
We are a global organization where EPDM licenses are drawn from Europe. I work with our EPDM manager located in Germany. I have built the North American EPDM structure for our business unit from SolidWorks World training. I recognize you from asking questions in Lindsay's course this past year and have actually listened to one of your courses online. We are currently preparing for a 2016 PDM Pro upgrade and ran into this issue. We have found a workaround and will investigate root cause more thoroughly with your advice.
Retrieving data ...