Where in the database is the dataset number stored please?
Can someone please show me where in the database TRIM stores the 45 or 47 dataset number?
OK, but what I'm not following is if they are in the wrong location, wouldn't it just be simpler to reverse the change and move them back physically rather than changing the store ID?
Going from what you have said above:
TRIM thinks this document should be located in:
But it is actually located in:
If TRIM thinks it is in 47, what happens if you just grab the document from 45 and drop it in 47?
Test with one and see what happens.
I'll be honest this is a lot messier that I would like. You would want to be sure that this is correct before modifying 19K documents.
Backup would make a lot more sense
It's a lot lot messier than I would like too. I'm the Records person, not the IT person, so my primary concern is the recordkeeping. This is not sitting well with me at all.
My understanding is that we don't know when this happened, and we weren't able to find a backup with all the documents in the right place, so the backup option is off the table.
I tried moving a document into the 47 folder in the same spot as it is in the 45 folder, but because all of the documents were replaced by markers in the integrity check, it doesn't do anything. TRIM has reassigned that particular document to a new location where it keeps the marker, instead of where the documents are. Unless there is a way of resetting that, it won't work.
Leave this with me for a while and I'll get an approach together.
IT suggest that as the documents are actually located where we want them, and it's TRIM that's pointing to the wrong folder to find the document, it should be possible to create a VB program which searches each document for the known text, then searches for the appropriate name and locations, then copies that document to the new location over the top of the integrity document, so that we end up with the original document replacing the integrity document.
I don't really like it. It seems like there is a bit of room for error and it could end up in a bigger mess than it already is.
OK, think it might be best if we do this through the proper channels.
can you log this up as a support case and let me know the case number when it gets emailed to you?
I'll work with the support officer assigned and we can go from there.
We only have one document store. We know the dataset number that we're using, we were just trying to find where TRIM stored the addresses for where the documents point so that we could fix it because some of them are wrong. We're currently working with HP support for this now though because it's not been a straightforward issue.
Thankfully we have a workaround and are able to restore our documents as required so there is minimal impact on users, but we're still working on a proper fix.
Looks like you have two different DataSet registered under the same Workgroup. HP TRIM creates heaps of database tables (within the SQLServer or Oracle ). These tables have column based relationship, the common configuration information like Dataset ID is stored in TSWKSYS table as one of the row values (DBID). There are other tables which defines the Document Store ( filesystem location), this Document Store folder structure is consist of DataSet ID as one of the folder name and underneath it creates further Filesystem folders where it actually stores the files.
When you login to HPTRIM you actually connect to a Workgroup server and a particular DataSet (behind the scene some particular database), when you upload the documents it stores the document related metadata and other system information inside the datase and stores the file in the Document Store ( Filesystem) under that parent DataSet folder, System extracts the documemt store location from the Enterprises studio and DataSet ID from the database and expects the DataSet ID name Folder on the filesystem under the Document Store location as explained above. Within the database tables you will find the entries (rows) about the document and its location on the filesystem which also shows the DataSet name as one of the parent folders on the filesystem.
In your case, it seems that you have two datsets ( you will be able to see two folders 45 and 47 on the filesystem as well). It could be possible
- that the missing documents were loaded when connected to DataSet 47 instead of 45 and that is the reason you see those files under 47. ( if this assumption is true than you should not be able to find the records of that file in 45 DataSet at all)
- That some one connected to Dataset 47, registered documents and files which goes in 47. Later on IT or someone did the Database Export from 47 and Imported into DataSet 45 without Copying the actual files under Dataset 45.
Can you please check that you only define the actual DataStore location in Enterprises Studio only and under the TRIMClient - Tools -System Admin -Document Store you only find %global% ( not the actual path of filesystem).
- that someone or group of people ( check the owner or assignee of those missing docs if its particular person or some specific group of people) have Linked Folders from Outlook which they initially connected to the Dataset 47 and registered the documents and even now the TRIMClient is connecting to Dataset 45 however the outlook linked folders are still pointing to 47, that means the documents registered through those linked folders will be in 47 Datset folder.
In your case if you can identify the documents in 47 which should be in 45. You can SuperCopy and register them in 45. However as a best practice it will be good to find out how those documents got into 47 instead of 45. If you check the above mentioned points you may be able to find the root cause.
Hope this help.
Hi there Harry
Thanks for your help. We have found our cause (PEBCAK) and are working with HP support to find the fastest and easiest way to fix it. Appreciate your response.