FVItems remain but not tied to Application Data

[avillanueva]

I am in the file stage of my vault move and clean up. There are 0 files in the remaining folders but a Query Builder report show 50 files remaining.

When I executed a vault WContent verification check and everything comes back clear. No missing files. huh? I created a new report to check the FVItems against ApplicationData and it shows that there is no ApplicationData tied to these FVItems at all. Bad data? I would thing so. All show 0 bytes in the DB too. Now this article says that the CommonScheduleQueue should clear those no worries. Except that I waited a day and nothing. These also have existed for many weeks and odd that the timestamps show recent.  I think my only recourse is to remove the offending lines records right? Is there any other thing that can be tied to these?

[mmeadows-3]

Are the files in the external file vaults or the BLOBS?
Query ApplicationData for associations to the mainvault.  This article shows the relationships for building the query.
https://www.ptc.com/en/support/article/CS121641

Are they recently created?  Remove Unreferenced Files doesn't typically pick up files created in the last couple of days.  Sometimes I wait a few days and remove unreferenced files again.

It has been a while since I did a full revaulting.  As I recall, revaulting cannot work for missing content files, zero length files, or incomplete business objects.  You may need to manually move them at the DB level.

[avillanueva]

I created this QueryBuilder report to get the data on the 50 FVITEMS:

ApplicationData to FVItem is outer joined so if the FVItem does not appear in the ApplicationData table, it will show nulls. I am also looking specifically at the the vault I am trying to remove which reports to have only 50 items matching this report. Notice AppData ID is null indicating there is no ApplicationData object referencing this FVItem.  Junk data? 

[avillanueva]

Thanks @mmeadows-3 for the help and information. I wrote this query to help get to the bottom of things:

SELECT COUNT(*)
FROM FVITEM
WHERE FVITEM.IDA2A2 NOT IN (SELECT IDA3A5 FROM APPLICATIONDATA)

Looks like there are 178 objects to deal with. This is the main article that deals with my issue:

https://www.ptc.com/en/support/article/CS45217

I checked and the PurgeUnreferencedFvItemQueue is empty (odd) and I do not have values called out in that article.  Perhaps that is the issue. I would assume once I add them and restart, that a queue job would be created to process that and clear my issue. Much better than DB hacks.

[avillanueva]

Actually, looks like a restart might be all that's needed:

https://www.ptc.com/en/support/article/CS277792?source=search

[avillanueva · Accepted solution]

Not quite. I can see that the job ran but there was no result. Odd. I ended up manually removing the 50 lines after backing them up. The remaining vault folders were remove and then the vault was removed so looks like I am all good. I will have to further play with this task since it does not appear to be functioning. One remaining question I have is why is this task running in the commonSchedlingQueue (executes on start up I can confirm) but not in the PurgeUnreferencedFvItemQueue? Perhaps its the age of my system when PTC ditched the queue in favor of the common one. Hmm. Anyway moving on...

[avillanueva]

PS: Also learned that this rule applies when you trigger manual delete unreferenced files:

• The following property controls the handling for unreferenced Files
  • wt.fv.purgeUnreferencedFilesOlderThan - age of unreferenced files on the disk before they are considered for deletion (in days)
    • Set this property to 2 or higher
    • When this property is set to a value less than that, it will automatically default to 2

I can see it clearing my default cache vault folder but only files older than 2 days which is minimum setting.