Skip to main content

We are running Apps10 UPD8.

We are currently testing moving our document repository from the DB to an Shared Folder.  We are getting a lot of “failed to move” errors with File not found in the repository 'DEFAULT' on the individual files listed.  Digging into it further I found

  1. Files that have this error in our test environment cannot be viewed in our Production environment.
  2. In the majority of cases, there is no “Checked In” record in history and the view button is not enabled on the General tab.
  3. In a few cases, there is a “Checked In” record in history, but view errors out when it can’t find a file.
  4. I have not yet established if there is a pattern associated with our IFS version when the document was created (Apps8 vs Apps10).

I’m thinking about doing the following to move forward.  I’m wondering if anyone else has run into this and has recommendations on what worked.

Plan to go forward.

  1. This error really means the file doesn’t exist so there is no “get the file back” in this scenario.  This project only brought the problem to our attention, it didn’t create it.
  2. Create a report showing all Document Revisions that are in “Checked Out” status but do not have a “Checked In” history record.  This means the file was never uploaded to IFS.
    1. Confirm can’t view these documents at all
    2. Figure out a way to delete these records (migration job?) from IFS before doing real document move.
  3. Not sure there is a way to ID the documents that have a Checked In history record but really aren’t there (get error when trying to view). 

"a way to ID the documents that have a Checked In history record but really aren’t there"

From IFS Enterprise Explorer, this advanced saved search from Document Revision will show you the checked-in documents that don’t have database storage. (I tested this in Apps 9 UPD13 and Apps 10 UPD7.)

edm_db_state = 'Checked In' AND (doc_class, doc_no, doc_sheet, doc_rev) NOT IN (SELECT doc_class, doc_no, doc_sheet, doc_rev FROM &AO.edm_file_storage)

 

When we made this transition, we had hundreds of gigabytes of documents to move, and I ended up writing my own utility to do the move more quickly so the job could fit inside of a 12-hour maintenance window.

The IFS method goes from the database, to the extended server, to the FTP server.

Ours went from the database straight to the FTP server, via a UNC network path, saving a hop and providing better visibility. It used an on-database Java routine to write the files.

It also hashed the file contents before and after to confirm everything transferred completely.

Hi,

A bit late to the party here, but I just wanted to verify your theories above. Those documents, on which the system cannot find a file, is not complete. Most probably "something happened" when the user tried to check in/upload the file. It happens, unfortunately, in a few different scenarios (network problems are the most common scenario, but there are different variants of them, crashing clients might be another reason, and there are more...).

We have of course tried to make things as stable as possible, including giving good errors and adding ways to fix common scenarios, but it's still not waterproof, so depending on how you run the system, how many documents and users you have, etc., you might get a few or more of these after some time.

If there is anything we can do that would help you, "after the fact", so to speak, don't hesitate to file an official support issue about it (we don’t always have the bandwidth to take concrete actions on things reported in this forum). There might be proper bugs that we can fix or messages that can be made better or checks that can be added. And we can also add a functional request to be looked into later.

/Mathias
 

Terms & ConditionsCookie settings