Unlock a world of possibilities! Login now and discover the exclusive benefits awaiting you.
I am looking into the .xml-files in the QVPR-folder, and it appears that the .xml-files contain IDs and names of .qvw-files, which don’t exist on the hard drive anymore.
Does anyone know which file in which .xml-file determines whether the SourceDocument appears in the QMC or is a “ghostID”? Additionally, is there a way to remove the IDs of deleted .qvw-files from the SourceDocument.xml and DocumentTask.xml respectively?
Hi, maybe there were files that were scheduled to reload, but the file was removed before romving the schedule.
You can create a qvw with the same name so you it takes the old configuration and you can disable any scheduled reloads and/or document cals assigned and then remove the files.
Hi. Thank you for your suggestion.
If a document was scheduled and the document is removed without removing the triggers, then the tasks is showed as offends in The QMC. These tasks have been removed properly and are no longer showing in the QCM. We have over 700 of them, so my guess is that it is every task ever created and then removed again
Can you either attach a recent QVPR backup zip file for me to have a look at, or send it to me in a personal message? I can try to see if I can spot what may have occurred. My hunch is you may have changed something somewhere along the line and recreated everything from what you are describing, should be able to clean things up, but need to see things first.
Regards,
Brett
Are you able to open a Support Case and attach it to the Case? If you can, go ahead and do that and then you can personal message me the case number, and I can go find it and have a look at things to see what may have happened. Only way I am going to be able to shed more light upon things. The videos you were watching were likely my recordings from a few sessions I have done on things! 🙂 They get you on the right trail, but they were not designed to go this in-depth. I am an employee just FYI, my Community tag may be a bit misleading in that regard now! 🙂
Regards,
Brett
Yeah, the key thing to keep in mind in the QVPR is 'orphaned' GUIDs will normally create issues, but you have to be very careful cleaning things up. As long as you have a good backup to fall back to, there is really no harm in attempting to do things, as if you mess up, just restore and try try again! 🙂 If you have specific questions on anything, let me know, I should be able to shed some further light upon things, but the biggest challenge in most cases is being able to figure out whether you need to remove something or get the correct GUID assigned, that is the most tricky part of things.
Regards,
Brett
Today we have been trying to just delete the Ghost documents rows in the QVRP folder. They are only in the SourceDocument and don’t have any triggers. But when we have removed 10 ID's and waited an hour the QMC made them again. We will try to se if it is possible for us to get directly in contact with you Brett, but he process will properly be quit long.
From what I could see in the QVPR files, those QVW files have to be residing in the Source Document Folder paths to which they are assigned, as there is nothing else wrong in the QVPR files that I could see although a bunch of information was masked out, so I could not tie out everything I normally would, but from what I can see, the issue should be that those QVW files actually do reside in the folder paths... Removing them from there will remove them from the QVPR SourceDocument.xml file and thus from the QMC, but may need to bounce the QDS service to make it happen sooner versus later. If any of those QVW files had tasks associated with them, those should automatically move to the Orphaned Task folder under that Source Document Folder to where you can click on those tasks and delete them if they are no longer needed to fully clean things up. Any QVW files in any Source Document or User Document Folder path will be read by the QDS/QVS services and posted to the QMC, this is as-expected behavior as the services scan the folder and any subfolders and write out any files found. I wrote things up on the case too, but I wanted to answer here too, just shout in either place to let us know if this was the issue or not.
Regards,
Brett