Skip to main content
  • EN

I have a workspace that is trying to write to an Esri enterprise database (in PostGis). One particular layer errors out with An error occurred while attempting to open the table, feature class or relationship class 'xxxx'. The error number from ArcObjects is: '-2147216011'. The error message from ArcObjects is: {The SQL statement was not a select statement}

I’m unclear what sql statement the process is trying to run as no ‘sql to run before write’ was specified when the writer was created.

Other similar layers pass through and write with no apparent problem. Disabling that layer allows the process to run. The fields are named in similar fashion to the other layers.

Esri told me to try writing out to a file gdb first (the File Geodb writer had no problem) and then read that into the enterprise version but the source format doesn’t seem to affect it. Obviously there is something the ArcSDE Geodb writer does not like about that layer, but I can't see it. What should I be looking for?

 

@bigclyde Looks very similar to this problem (although a different error code). So check that the table you're trying to right to is actually enabled in the geodb and not just a PostGIS table.

(added the link!)

Sometimes weirdness happens when privleges set by the DBA get a little messed up so that you can get one feature class/layer that will just misbehave.

A few things to test are:

  • Inspect the feature class/table in ArcCatalog using the connection credentials used in FME. Each Feature class you tell you whether you have "SELECT, INSERT, DELETE, UPDATE" permissions. This is by Right-clicking the feature class/table and looking at its Properties
  • Similarly at the same time look at whether or not it is Versioned or not, and whether the other surrounding FCs/tables are Versioned or not. If it is different from the others, this is often another cause of write/update permissions issues often requiring the DBA to fix up.
  • Test whether or not the Feature Class/table can be updated from an edit session in ArcMap

@bigclyde Looks very similar to this problem (although a different error code). So check that the table you're trying to right to is actually enabled in the geodb and not just a PostGIS table.

(added the link!)

Thanks Mark,

I discovered by accident that the difficulty appears to have been with the table name. ‘address_node’ was not allowed. Somehow ‘aaddress_node’ ‘address_ode’ ‘_address_node’ ‘address_nodes’ and a few other variations were all ok, just not the one I actually wanted.

Also unacceptable were ‘street_centreline_future’, ‘aih_lp_pipelines’ and ‘contour_50cm’ (although ‘contour_1m’ and two dozen other ones are just fine).

I don’t see much of a pattern those names. Is the writer really that picky? Is it an ArcObjects thing?

Thanks Mark,

I discovered by accident that the difficulty appears to have been with the table name. ‘address_node’ was not allowed. Somehow ‘aaddress_node’ ‘address_ode’ ‘_address_node’ ‘address_nodes’ and a few other variations were all ok, just not the one I actually wanted.

Also unacceptable were ‘street_centreline_future’, ‘aih_lp_pipelines’ and ‘contour_50cm’ (although ‘contour_1m’ and two dozen other ones are just fine).

I don’t see much of a pattern those names. Is the writer really that picky? Is it an ArcObjects thing?

@bigclyde I agree with @bwn, I don't think this is FME. I suspect these tables exist somewhere else in your database that you don't have permission to view or write too, or something along those lines. Perhaps talk to your DBA or Esri support to see if those tables exist. Please let the forum know if you do find anything.

I'm still don't understand the exact cause, but somehow ArcCatalog wouldn't communicate with those particular tables even though they existed in the db. At the same time it somehow locked them so FME couldn't overwrite.

The solution turned out to be: 1) generate the table with a similar name 2) from Postgres, drop the original table and rename the new one to the original name 3) from ArcCatalog, drop the new one. After that, it worked.

Reply


Community Stats

30,110
Posts
114,303
Replies
37,745
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.