Are you reading from and writing to the same file geodatabase in the same workspace? Then I suspect you are locking it, preventing workbench to do it's thing. This might work on desktop using featurecaching, because you are working step by step through it, but not when featurecaching is turned off, as on server.

no, read one .gdb and push to AGOL

OR

read from one .gdb and write to another .gdb

I rarely use featurecaching.

I don't think it's a locking issue. That is usually a different error. Thanks for the reply 🙂

Might it be a permissions issue then? We had some issues with files created by users which could not be edited by the fme server user, it not being the owner. Removing the user created files and let them be created by the fme server user solved this.

worth taking a look thanks for the suggestion

We are encountering the same issue.  Is there a resolution to this?  We have tried all the suggestions in the Community forums to no avail. Our ArcObjects Error Number is: '-2147024891' rather than '-2147024893'.

We are reading from two different SDE featureclasses, doing a point in polygon operation, then reprojecting a couple of fields to Lat/Long coordinates from State Plane and creating two fields to hold the coordinates, doing some other calculations and writing to an intermediate file geodatabase featureclass.  The two source SDE featureclasses have over 300,000+ records each and looking at the log output in FME Flow (Server), there isn’t a problem with reading the information from the SDE geodatabase featureclasses, just writing to the file geodatabase.

This file geodatabase featureclass is an intermediate output and gets processed by two other downstream workspaces that also do some geoprocessing and introduce other input in Excel spreadsheets. Ideally we would like to string the process together in an FME Server automation with an email sent on success or failure, but Step 1 workspace fails in Server.

All three run well from FME Form. Both our FME Form and FME Flow versions are the same at 2022.2.7.  Our output file geodatabase resides on a networked drive, but I did move it to the root of a mapped drive.  I changed the name of the file geodatabase to be 11 characters or less with no spaces and also the name of the feature type to be 11 characters with no spaces, obviously. I have “Administrative” privileges on FME Flow.

Sheila

Kern County, CA, Information Technology Services, GIS Programmer/Analyst

I saw something like this when we were using the dataupload service and the staging dir was on a fileshare - the resultant path breached the default ‘max path length’ of 256 chars I think?

the answer was to either switch the servers to support long path by default, or to prepend the \\?\ to the front of the reader path (which is ultimately what we ended up doing as it was to hard to convince people to switch on long path support!)

If this rings bells with your situation, then more reading can be found here: Maximum Path Length Limitation - Win32 apps | Microsoft Learn

Without directly solving the issue, personally I try to avoid using FGDB for staging/intermediate outputs, primarily because other formats don’t have some of its limitations/negatives.

Something like Spatialite or GeoPackage I find have far better utility as a temporary/intermediate file format for downstream processing.  FGDB I tend to only use as a final product for publishing.