DWF Update error....

[cbenner]

What type of setting might be causing this error.  I get this when I try to either update or delete a visualization.  My DWF files are created when I check in the file from CAD.  I can delete the dwf directly using the Admin override (ignore warnings and delete).  I'm sure I have something checked somewhere that is causing this... but I haven't found it yet.

[DannyvanDuijn2]

Hi Chris,

It is most likely a settings issue with access permissions.

Perhaps the Access Control List on folder level is giving you the trouble. Are you using lifecycle definitions with automatic assignment of files? Check these settings also.

[Bill.Schmid]

We've had about 4 or 5 files in Vault Professional 2013 that kept erroring out in the Job Queue.  They just wouldn't get their visualizations created.  I finally tried creating them directly and saw an error that it couldn't delete the dwf.  So I went and found them and deleted them manually and then the visualizations worked.

I'm with the original poster, why does this happen?  It's like, hey Vault, they're your files - figure it out.  At least it wasn't that many files and I know what to look for now and how to fix it.  But it still shouldn't happen.

[jddrinkwater]

I am guessing that like me, you read the ones-and-zeros article that suggested you have the DWFs automatically assign themselves to a category and lifecycle which defaults to 'released'.  This was useful for allowing the limited permissions users make use of the vis. files (like our shop guys looking at the web viewer).  

I'm pretty sure you've stumbled onto the same big problem i did, which is that since the DWF is released, it needs extra permissions to delete.  Even with full permessions the my job processor can't delete a file which is marked 'released'.

it gets better - you can't change the lifecycle, state or category of a DWF, so every DWF in the vault is locked, with this potential problem lurking.  I see this error many times daily in the job queue log, and there is nothing practical I can do to deal with it (I can't search, delete and regenerate 5-50 DWFs every day).  I am contemplating deleting and regenerating all 35,000 DWFs in my vault to get over this, but that is a huge task.

Sorry to be negative, good luck, hopefully there is a better solution out there!

John

[JamesMcMullen]

Does the Job Processor user have edit permission to the released state?

-Jim

[Bill.Schmid]

In my case, the DWF's weren't in the released state, they were work in progress.  Trouble was, it said they were checked out.

That makes me wonder: does the job processor "check out" the dwf when it goes to generate the new dwf?  If so, here's my imagined scenario: The job processor gets the Inventor file to generate a preview for, it checks out the existing dwf, then goes about creating a new dwf from the Inventor file.  In a perfect world, it would create a new dwf and check it back in to replace the old one.  But, the copy of Inventor that was summoned by the job processor crashes while it's trying to generate the dwf.  Job processor throws an error and continues on to the next file in the queue.  This leaves the dwf in a checked-out state and nobody else can check it out until the original user checks it back in, which will never happen.

Does that sound possible and/or probable?

[jddrinkwater]

Hi Bill,

the job processor does crap out every once in awhile, and when it does, it tends to leave the associated DWF checked out.  Happens a few times a month with our vault.  the easiest solution is to log in to the vault client as the job processor, search for checked out files and 'undo checkout' on the affected DWFs.

James,

The job processor account has full vault permissions (admin, doc. editor etc.) as well as permission to read/modify/delete/ the released state files.  The issue seems to be the prompt that comes up when you attempt to delete a released file.  If I log into vault as the job processor user, i can delete the DWF, but only after expanding the dialogue box and ticking the 'ignore restrictions' box.  it seems that the job processor doesn't do this, so it can't delete those DWFs.

John

[JamesMcMullen]

Do either of you have a custom job around the Job Processor?  The reason why I ask is that I just tried the operation and I really do not see that we delete the DWF.  I still have multiple versions of the DWF.  Is it possible to turn on for a moment, the "Show hidden files" option from inside Vault Explorer?  I am interested to know if the DWF is assigned to a different category from the file.  I am expecting the DWF to be in the "Base" category state.  Also, if you left the default columns on in Vault Explorer, is it possible to get what "State" the DWF file is in that you are displaying the problem?

Thanks,

Jim

[jddrinkwater]

Hi Jim,

Attached are some screen shots.

If I had to guess, i believe the issue occours when the rules say the link between DWF and file should be broken.  See my last screen shot.

[mbodnar]

Sorry if I am missing something, but I thought the DWF's should belong to Category Base that has no lifecycle and/or revision attached to it.

That is how I use it, but still have experienced DWF's that

1. Cannot be updated by the JP because duplicate names exists. How I dont know

2. Cannot be created by the JP when a manual update creates the DWF just fine

Regards

Max Bodnar

[cbenner]

Wow,

I had forgotten this topic, looks like it's gotten a lot of traffic in the last few days.  I'll throw in my two cents worth since I opened this can of worms.

In our case, the dwfs are all being creted manually on check in of the file. (no JP)  All are being set to the same category as the files (in our case we it's called projects).  All are created and left in the WIP state. 

However, and here is something I have not yet tested, we do use Item Master, and set the Items to Released when the drawing is ready for production.  I'm going to look later this morning to see if the problem could stem from trying to update or delete a dwf that is linked to a Released Item.

EDIT:

So far I have been able to Update the dwf of several files where both the file and Item were set as Released.

I haven't run into this problem in a while, and I've had a very full plate so I kinda forget the problem was out there.

[JamesMcMullen]

John,

I am unsure why you are assigning your DWFs to a category.  I would like to understand your workflow a little better.  As Max pointed out, you really want them to be in a base category.  The reason being is that in the “Simple Release Process” and in the “Released” state you must add the Job Processor with the appropriate permissions.  I would also like to know why you are deleting the DWF.  If you delete it, I would think that you would lose historical values if they are needed.

Max,

I think there is an issue here.  For #1, is it complaining that the job name is a duplicate or that the DWF file already exists?  What version of Vault are you using?  I think it would be best to go through Customer Support to get a fix for #2.  I would expect that if you can create a DWF manually that the Job Processor would be able to create the DWF as well.  Having the one method work tells me that there is something wrong.

Chris,

I know an Item in a released state will lock a file.  It does not put one on the DWF file.  As I mentioned in a previous post, does the Job Processor user have access to your “projects” category and full control in all of its states?

-Jim

[cbenner]

Hi Jim,

We don't use Job Processor for any of this, but having played with it at one time.... yes the JP user has full rights to everything.

I haven't seen this issue for quite some time.  I was trying to remember what I was doing when I first posted this to try to help the two guys that are still having issues.

[mbodnar]

Hi James

I have a support ticket on issue 1 and 2 and working with tech support to resolve it.

Client is using Vault WG 2013, and for some reason it sometimes complains about duplicate DWF's existing. We checked duplicates and none come up, so strange that it would complain about duplicates

Yes I agree that is a manual update works, the JP should be able to create the DWF but it does not

Admin had full rights in lifecycle scheme to update DWF. Running JP as admin

Max

[Telson.Hadden]

4 years later, same issue, any new ideas/info?

Not related to any particular file, just every so often, the JP won't make a dwf.

[a.murphyYHDY8]

Ran into this issue with a customer. Couldn't update the dwf visualisation for about 500 of their files using the Job Processor. Discovered the cause was a user had applied a label to a number of folders in the Vault and this label had gotten applied to a number of the hidden dwf files.

Deleted the label then re-ran the jobs in the queue, problem solved.