Hi Fleur,

A "shapefile" traditionally consists of multiple files. There should be at least a .shp, a .dbf and a .shx file, and optionally some others.

(Here you will find a clear explanation of what a shapefile actually is, written by Max Dietrich, a Geospatial Developer from Rosenheim, Germany.)

Your error message is: "Shapefile Reader: The .dbf for (...) could not be found." The cause of this error is, most probably, the fact that the .dbf file is not at the location where the system expects it to be...

You say that when you 'Run Workspace' you only upload the .shp file. But, again most probably, you do so from a directory where the other files which are part of your shapefile are also located (i.e. the .dbf, the .shx and possibly some other files). So the system can access al the information it needs and process your workspace.

I guess you have to make sure that when a colleague runs the workspace through the Workspace App they also provide the the full shapefile, and not just this .shp thingy...

HTH,

Egge-Jan

Hello Egge-Jan,

Thanks for your reply. Unfortunately, I am not quite satisfied with your answer.. To my opinion the Run Workspace function should not work differently running the workspace through the Workspace App, which should merely function as a shell - or interface, you name it - around the same function.

I know what a shapefile is and I know the function of the .dbf and other supporting files, that is not the issue. The issue is that I expect FME to find the supporting files when uploading just the .shp file, just as it does when I run the exact same workspace with the exact same .shp file as input by using the 'Run Workspace' functionality. Other workspaces that I run through a Workspace App run correctly after merely uploading the .shp file.

I am quite annoyed how inconsistent FME Server is at this point and find that the feedback that I receive in the log does not help me any further to make it work the way I know it should be able to work.

Thanks,

Fleur

OK - this is important information. You say: "Other workspaces that I run through a Workspace App run correctly after merely uploading the .shp file."

So, it sounds like the issue is specific to this workspace and/or the input shapefile. In the end it should be possible to get your solution running through a Workspace App, but this will require some testing. Are there - apart from the message on the .dbf file - any other hints in the log file on what might go wrong here?

@fleuranna​ I don't think you're understanding how FME Server works in this instance. I am making one assumption, that the .shp you're trying to use is on your local computer

When you submit a job to FME Server that requires an external file, it is uploaded to a temporary directory on FME Server. As you are only specifing the .shp, only that is uploaded. Then, when the job is run, FME Server looks in that temporary directory for the .shp and associated files and can't fidn the .dbf as it wasn't uploaded.

When the job is running, it can't access the files on your local machine. This isn't an FME issue, it is a core security measure across the entire internet.

When dealing with .shp the best way is to have the process accept a zip file that contains all of the required files for the .shp. FME treats zip files as directories so it can easily read in the zip file.

Hello hkingsbury (and Egge-Jan), thank you for your response. At this moment I instruct my colleagues upload a .zip file indeed.

I have been able to reproduce what caused the inconsistency that I experienced and irritated me. A had the false assumption that the uploaded files would be erased after each successful run of a workspace. During testing I used two different shapefiles. I ran the workspace multipe times using the 'Run Workspace' function, sometimes uploading all the supporting files and other times uploading merely the .shp file. Both would work, and because our FME Server has access to the networkfolders that I work on, I assumed (false assuption number two) that FME Server would 'find' the supporting files by itself. Quite like QGIS does when merely opening a .shp file. Because the previously uploaded (supporting) files were still findable for the workspace as they were not yet erased from the temp on FME Server, the workspace would have a successful run - which kept my assumption alive. You now explained to me that the security settings on FME Server do not allow for such automatic localization of supporting files in networkfolders.

My irritation started when running this workspace through a Workspace App and the run would be unsuccessful. I now know that with such a run, FME Server creates a new folder within the temp folder. So if no .dbf was uploaded, then no .dbf will be found by the workspace.

In short, the inconsistency that FME Server appeared to show was in fact not existing. It were my own wrong assumptions - which were based on experiences with QGIS software and the lack of relevant feedback from FME Server.

Thank you for your time!

Good to hear the issue has been solved 🌻