Solved

Has something changed in FME 2020 when reading zipped File Geodatabases (GDB format)?

  • 11 December 2020
  • 3 replies
  • 12 views
A
Badge

I'm in the process of migrating a number of workbenches/workspaces from 2018 to 2020. Many of these were created years ago in much older versions of FME. So I'm meticulously going through an updating all elements in the workbench, then running it in Desktop and finally publishing to Server 2020. Running into very few issues but I can't get Desktop 2020 to read zipped GDB using the GDB reader. Where it does so in 2018, it fails in 2020. 

 

Unable to connect to the File Geodatabase at 'path..../GDBName.zip'. Make sure the correct 
filename was specified, and that the geodatabase wasn't saved with a newer version of ArcGIS than the one installed locally. 
The error number from ArcObjects is: '-2147024893'. The error message from ArcObjects is: {}
A fatal error has occurred. Check the logfile above for details

It will read the GDB just fine if I manually unzip it in the same location. So it's not permissions or issues with a bad GDB. Anyway, I can come up with a workaround - just wondering if there were other changes I need to be aware of.

icon

Best answer by andreaatsafe 11 December 2020, 21:34

View original

3 replies

A
Rank
Badge +10

Hi @agelfert​ ,

Sorry to hear that you've encountered this issue.

 

When you are reading from a zipped file the file is unzipped into a temporary location. Along with this, we did make a change where each FME run creates its own folder in the temp location. This likely lead to the change in 2020 and created longer file paths, hence why you are receiving the error message that it's unable to read the geodatabase.

 

If you are on Windows 10, can you try enabling long file path support by following the steps in this article.

 

We also recently made some updates to shorten the generated temporary file paths. This is in the next FME 2020.2.x release (tentative for January) and our latest FME 2021 beta.

You could check out FME 2021.0 to see if it can read the zipped geodatabase: www.safe.com/beta

 

If you're still encountering an issue after trying the suggestions, please file a support ticket for us here: https://community.safe.com/s/submit-case

- Andrea

A
Badge

Andrea,

 

Thanks for your reply. Sorry about the lag in response time. The above referenced tweak has fixed the issue both for desktop and server. Glad to report I was able to migrate the processes in question to FME 2020.2. Happy New Year!

Arne

matthew_banyard
Rank
Badge +3

Just wanted to add I've had the same issue in 2020.1.

Unfortunately upgrading is a rather cumbersome process, so it'll be a while til I can test in 2020.2.

 

Input was a zipped foler containing (amongst other things) a file geodatabase (I wouldn't personally say any of folder / geodatabase name / featureclass names were unreasonably long)

 

With the 2020.1 changes to tempfiles, by the time it's unzipped it was pretty much already at the limit, as the FME temp folders folderpaths created are a tad verbose.

 

Changing the Windows LongFilePath setting provided a partial fix, however Python scripts further downstream were also affected - needing a similar upgrade.

 

Hopefully 2020.2 is a little tighter in it's tempfile file and folderpath lengths

Reply


Community Stats

28,707
Posts
109,479
Replies
36,552
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.