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?
If you are referring to the dataset ID?
If so you can see which ID is attached to each DB in the TRIM Enterprise Studio.
There is also a way to tell from the reference file - TR5 file.
Right mouse click on the reference file and open in a text file, it the value in red below.
[TRIM Context Reference]
Open it up and they appear next to the database name.
Also in the properties of the dataset, it is the 2 character identifier. In the case below 88
The back story:
We have a number of documents that are "missing" at the moment. It turns out that TRIM is looking for these documents in a folder path that includes the number 47 where it should actually include the number 45. We're trying to find out if there is an easier way of fixing this than re-adding all the documents individually, especially now that my drag and drop function doesn't work anymore.
Hope that makes sense
Might be easier if you tell me what you are trying to do.
If you know the database name you are searching against, then the document obviously belongs in there.
Is this something to do with the integrity check that you ran in an earlier post?
Sorry just saw your additional post.
So have they been missing since you ran an integrity check? And more importantly are you receiving an error message in the client?
I'm not sure when it all went wrong. But they're not actually missing, they're just not where TRIM thinks they are.
TRIM thinks this document should be located in:
But it is actually located in:
We just need to find a way of changing the folder that TRIM thinks the document is in.
Are you 100% sure that is the correct document?
45 and 47 are your database ID's for 2 different datasets. The problem you might have is that a file name like 00+c00000fk.pdf for example can be used more than once is different datasets.
So before you try and make any changes just confirm the documents are correct.
The easiest way to resolve this is go to a backup of the document store when you know the documents are in there.
It is extremely unlikely that the documents would have moved to a different store ID, only with someones intervention.
Yes, I am 100% sure that that document is the correct one.
It's possible that someone unknowingly moved them in preparation for or during the upgrade last week, but there's not much we can do about that now.
It's also possible (likely) that there are around 19k documents that have been affected by this. All of the documents I have checked so far have matched the locations exactly, except for the 45 / 47 folder issue.
I would personally be more comfortable adding them one by one as new revisions, but I now have to use TRIM Queue to put them in and it's going to take a really long time to do that many documents that way.