A place FOR CAD users BY CAD users
https://www.cadforum.net/
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.smf39 wrote: ↑Wed Mar 06, 2024 3:26 pm 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.
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 wrote: ↑Tue Mar 12, 2024 10:37 pm 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.
These files weren't private state. They were checked in but had no State due to some issue during a recover operation.
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 wrote: ↑Thu Mar 14, 2024 10:42 am 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.
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.smf39 wrote: ↑Sun Mar 24, 2024 5:45 pm 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.