@TheofilLepschy 

You can use the IFS CLoud storage migration tool to transfer the documents to the file storage. Kindly refer this f1 documentation related to this.

https://docs.ifs.com/techdocs/21r2/010_overview/760_file_storage_service/fsmigtool/

Regards,

Sahan 

Hi Sahan,

thanks for your post. I ‘ve read the documentation before , the documentation says, “Database repository only”:

In this case, we cannot use it. 

I would appreciate any input.

BR

Theo

You can use any page/projection that allows creating documents and uploading files or our Premium API CreateAndImportDocument API/projection. You can use any REST-capable tool to do it.

You can also use the Create DocumentS assistant to import at least hundreds of documents at a time, and you can provide values for some of the fields.

You can also use Test-A-Rest to do it, and I have previously posted here on IFS Community on how to do that.
 

Here is the post/comment:

Thanks Mathias, we will try it out!

/Theo

Hi Mathias, 

basically, we got all information about path and business objects references from legacy systems. In past we create all data in IFS (doc issue, edm file and doc ref object) via the standard stored procedures (script based) and coping files manually into shared folder. Now with „File Storage“ repository we went the same way and it seems that IFS cannot find all manually copied files. Manual checked in files are fine. Is there something new regarding file name usage or cache thing regarding the middle ware?

Hi @Mathias Dahl,  

the way you proposed it’s a little bit magic for us, we don’t have any clue how to do that.

For that reason, we have tried to import first the files in the database repository followed by the transfer to FS.

Migration to DB repository works fine, the files are there, can be viewed. The transfer to FS doesn’t work.

The transfer from DB to FS repository works fine for file which are not migrated into DB repositoriy.

What are we missing by the migration into the DB repository?

@Eric can give more information about the files in the DB if needed.

Thx!

/Theo  

The way you have done it should work and the reason the "migrated" documents doesn't work is probably due to some little field not having some data that we expect (the main suspects are dates or timestamps, user/person name fields and status fields).

I recommend that you compare two records, one that works and one that doesn't work, from these entities:

- EdmFile
- EdmFileStorage
- DocIssue

How many documents are we talking about here? Did you consider the Create Documents assistant as I mentioned?

Also, with regard to the "magic" approach, did you download the file in the post I linked to? It's actually quite well documented and it's a pity that you are not reaping the benefits of that approach since it's MUCH easier once you understand it.

Again, the approach you took might be old and trusty, but to be honest, 1990's called and asked to get the SQL scripts back...  

Hi @Mathias Dahl,

we were able to do it, I don’t know exactley what the issue was, probably something related to the user which was executing the transfer - not enoug rights in DMS. However, thank you for helping!

We can proceed now on this way: 1. import files to DB repository (aprox 7-8.000 files), 2. transfer to FS.

Regarding to your proposal to use the  MIG-Tool, I cannot access the link: http://techdocs/demoshowroom/21r2/010_demo_platform/020_running_scripts/

Another way to get this?

Regards/Theo

Great that you got it to work. If you have the time, it might help others trying out the same thing if you could describe in more details how you did the whole migration. Kind of paying back the community...  

As for that link, it seems that was a link that only works internally, sorry. The same tool ("TAR", or it's longer name Test-A-Rest) should be available to you though, via Build Place and is used to run the scripts there to input test data and run tests. Do you know anything about that?