Skip to main content
  • EN

I want to move an ESRI File Geodatabase (FGDB) from one folder to another. I have got the FileCopy Writer to move ...\\here\\data.gdb\\*.* to ..\\there\\data.gdb\\*.* but this leaves the now
empty ..\\here\\data.gdb folder in the original location. I suspect this is because FGDBs are actually folders which is confusing for non-ESRI stuff (to the FileCopy Writer, it's just another folder).


I know I could probably solve this with Python, or something involving Workspace Runners and FileCopy to nul to delete the folder after moving the contents. But I wondered if anyone knows of a way of doing this within the FileCopy Writer as part of the Move operation.

Before you suggest doing ..\\here\\*.gdb, the constraint is that ..\\here\\ may contain more than one FGDB, but I only want to move one at a time. This is because I'm processing each FGDB in turn then moving it to a "processed" folder.

I've also got an idea of writing the FGDB names (the names are dynamic) to a text file then having a clean up Workspace at the end which uses this to implement the "move *.gdb" solution.

Hi @conan_drumme, I could not reproduce your issue and managed to completely move a fgdb

by using the *.gdb path filter, but since this is not an option for you I suggest re thinking your process and possibly integrating the fgdb processing into your main workspace, so that once each fgdb is processed it is directly moved to the "processed" folder.

Hi @conan_drumme, I guess the cause for your problem is that you have configured the File Copy writer to move individual FILES. Try moving the gdb FOLDER. If you set YES to the "Copy Source Folder" parameter, the writer moves the specified gdb folder and all the files belonging to the folder.

Hi @conan_drumme, I guess the cause for your problem is that you have configured the File Copy writer to move individual FILES. Try moving the gdb FOLDER. If you set YES to the "Copy Source Folder" parameter, the writer moves the specified gdb folder and all the files belonging to the folder.

Agree, this setting works fine for an entire folder and its files.

 

 

Hi @conan_drumme, I guess the cause for your problem is that you have configured the File Copy writer to move individual FILES. Try moving the gdb FOLDER. If you set YES to the "Copy Source Folder" parameter, the writer moves the specified gdb folder and all the files belonging to the folder.

Thanks. That's done it :-)

 

I was also using the path_directory_windows attribute instead of path_windows.

 

 

I noticed you have a connection directly from path_windows to file_copy_source_dataset. I was using AttributeManager to rename the field. It took me a while to figure out that I needed to connect the Reader directly to the Writer to be able to do this. All part of the learning process. Thanks for that as well as it improves performance that tiny bit!

 

 

@takashi I am trying to do something similar to Tim, where I copy out a GDB at the beginning (in order to back it up) before I proceed with some data translation.

Considering that, where in a workflow would you recommend using a filecopy writer to back up the GDB before running the translation? Is there a way to set the priority of a reader? Or do you just recommend using a python startup script?

@takashi I am trying to do something similar to Tim, where I copy out a GDB at the beginning (in order to back it up) before I proceed with some data translation.

Considering that, where in a workflow would you recommend using a filecopy writer to back up the GDB before running the translation? Is there a way to set the priority of a reader? Or do you just recommend using a python startup script?

FME runs multiple readers in the same order that you've arranged them in the Navigator window of Workbench. Assuming that the workflow for copying consists of just a PATH reader and a File Copy writer (i.e. there is no blocking-transformer between them), I think FME runs this workflow at first if you put the PATH reader onto the top of the Navigator.

 

Reply


Community Stats

30,099
Posts
114,259
Replies
37,731
Members
Terms & ConditionsCookie settings
A product of
Safe Software respectfully acknowledges that we live, learn and work on the traditional and unceded territories of the Kwantlen, Katzie, and Semiahmoo First Nations.