Hi,

Could it be that the user running the workspace doent have the right permissions to access the gdb?

Hi @itay

That could be the reason, but I have tried to give the right permission to access the gdb but it doesn't work quite well...

Thx anyway for your words!

Br,

Felipe Verdú

Hi @felipeverdu1,

Can you specify why it is not working? and what permissions are set ?

Hi again @itay

I think I finally solved it throught restart of services (FME Server). I needed to this several times and this is weird...but I think it is working now.

Br,

Felipe Verdú

Hi @felipeverdu​ 

I had been getting the exact same error message. The workbench worked fine in Desktop, but then failed with that message in Server. I was pulling my hair until I accidentally looked at this line (Desktop log):

'0.2|INFORM|Connected to the File Geodatabase at 'C:\\Users\\<myUserID>\\AppData\\Local\\Temp\\FME_TempFileStore_1596819757681_29032\\dsGEODATABASE_FILE_4_1596819757682_29032\\MB_Facilities_HighPressurePipeli_1596819757682_29032\\MB_ENHHPL_GDB_LL83.gdb', which somehow looked to me as a quite long string.

The name of the zipped geoDB I was providing was 'MB_Facilities_HighPressurePipelines_IHS.zip'. The name of the workbench, FWIW, was also quite long: 'HS_FacilitiesHPPipesLPPipesGasFranchiseAreas_BCABSKMB_2_FileProcessor.fmw'.

In my case, simply shortening the name of the ZIP geoDB to 'MB.zip' made it finally work in FME Server.

As I see it, in my particular case at least, it was simply a matter of FME Server enforcing some max. string length rules and truncating the resulting file location string. Once I shorten some of the strings used internally by Server to build the file location, everything works.

Hi @jordimonk​ 

Thanks for your comment. I believe we solved the problem enabling long file path support. See the link below.

https://community.safe.com/s/article/windows-enable-long-file-path-support

Br,

Felipe Verdú