Files with blank State & Workflow

[smf39]

Hello! Our SW PDM vault has several thousand files without any State or Workflow. It appears to have happened somehow after a delete then recover operation. I'm unable to transition them to any new state. Any ideas on how I could fix this? I've been eyeing up the CurrentStatusID column of the Documents table, but am leery of messing with the DB. Thanks!

[AlexB]

That's a bit odd. Do you have any more details on what was involved in the delete and recover operation? I've restored vaults in the past and never encountered anything odd like this so I'm curious about how it was done. This will help me reproduce it if possible.

Also, I highly recommend against direct database manipulation. It will just about always result in problems.

[smf39]

I think the files were <Private State> but added to the vault, so they existed in the archive. I deleted them as Admin then recovered them around 30 min later, which left them checked in without a state. I tried reproducing it yesterday (in 2022 SP5) but they went into workflows correctly. At the time these files were deleted we were on 2020 SP5 and the category and workflow entry conditions had issues, so it may have been related to the old version or the bad conditions.

I was able to "fix" the issue in our test vault yesterday via the database but am running it by DS before doing anything in our prod vault. Yeah, the trouble with database mods is that it might appear to have worked, but then you find it's broken in some other area of the software. You don't know what you don't know. Cheers.

[smf39]

I checked with DS about my "fix", just got a generic reply about the perils of DB edits. I ended up just copying the problem files with a suffix, checking those in, then deleting the originals. I realised they haven't been visible to anyone but Admin anyway, since no users have permissions to view a state that doesn't exist. Thanks for the input.

[jcapriotti]

I think the files were <Private State> but added to the vault, so they existed in the archive. I deleted them as Admin then recovered them around 30 min later, which left them checked in without a state. I tried reproducing it yesterday (in 2022 SP5) but they went into workflows correctly. At the time these files were deleted we were on 2020 SP5 and the category and workflow entry conditions had issues, so it may have been related to the old version or the bad conditions.

I was able to "fix" the issue in our test vault yesterday via the database but am running it by DS before doing anything in our prod vault. Yeah, the trouble with database mods is that it might appear to have worked, but then you find it's broken in some other area of the software. You don't know what you don't know. Cheers.

Problem with DB edits is that the data in one table may also exist in other tables. So you change one table and it no longer matches the other which may or may not break something. The other "gotcha" is that some tables have triggers so you modify or delete something and it triggers stored procedures that do other things.

[Diaval]

I checked with DS about my "fix", just got a generic reply about the perils of DB edits. I ended up just copying the problem files with a suffix, checking those in, then deleting the originals. I realised they haven't been visible to anyone but Admin anyway, since no users have permissions to view a state that doesn't exist. Thanks for the input.

There is a user permission in the Folder permissions called May see files before initial check in (Private State). This option would allow the user to see other user's private state files prior to the first check in.

[smf39]

There is a user permission in the Folder permissions called May see files before initial check in (Private State). This option would allow the user to see other user's private state files prior to the first check in.

These files weren't private state. They were checked in but had no State due to some issue during a recover operation.

Problem with DB edits is that the data in one table may also exist in other tables. So you change one table and it no longer matches the other which may or may not break something. The other "gotcha" is that some tables have triggers so you modify or delete something and it triggers stored procedures that do other things.

Quite right! My test-vault fix was to update TransitionID in the TransitionHistory table for each file, which had a trigger to update the corresponding CurrentStatusID in the Documents table (desirable in this case). But I didn't end up doing this in the production-vault, erring on the side of caution.

[jcapriotti]

Quite right! My test-vault fix was to update TransitionID in the TransitionHistory table for each file, which had a trigger to update the corresponding CurrentStatusID in the Documents table (desirable in this case). But I didn't end up doing this in the production-vault, erring on the side of caution.

Yes, best to stick with doing things in the UI or API. There are a few tables that are safe to edit but its hard to know which ones. You 'll need VAR/SolidWorks blessing most times.