Features disappear

[DaliborKusic]

We have features stored in an Oracle 10gR2 database (SDO_GEOMETRY) with valid spatial indexes (r-tree, 2-dimensional). ArcSDE 9.3.1 with SP2 is installed. All features can be seen fine through 3rd party viewers, but when viewing through ArcMap connecting through SDE (either direct connect or through a service) some features disappear and appear depending on zoom level and panning (i.e. you pan a little to the right and features appear). What can cause such behaviour?

The same data in a different database (but still 10gR2) viewed through SDE 9.2 instance shows up fine through ArcMap.....

I've tried rebuilding indexes, even creating quad tree instead of r-tree...compared configuration options between these two SDE instances, but to no effect.... 😞

[DaliborKusic]

Your quoted link just says that tables with potentially corrupt geometries will be scanned for
validity with each query (with a performance cost). It does not say that corrupt geometries
will be processed or rendered, only that an attempt at correction will be made. If both Oracle
tools and 'sdelayer -o feature_info' report a geometry as invalid, it's invalid.

I understood that it says if the flag in question is not set (i.e. layer is created using sdelayer -o register), ArcSDE will verify the geometries prior to converting them and sending them to client. If they are "invalid" (i.e. vertical polygons) they will not even be converted and nothing will be displayed. However if the flag is set, the conversion proceeds without verification. This conversion and subsequent rendering may or may not succeed, but as it turns out it does succeed since the "invalidity" of the polygons is obviously not severe.

There is a third issue here: If ArcGIS sees a CAD object, it's going to use that over the invalid
geometry. It's very likely that the "it works" state is not due to ArcSDE permitting operations on
invalid geometries (it won't), but to ArcGIS ignoring the invalid shapes in preference to CAD
entities. Unfortunately, there is no way you can generate those CAD objects externally (much
less via SQL).

Didn't quite understand this part with CAD entities. Are you refering to the c in entity mask? I don't think this makes much difference since there are no CAD objects in the table and adding or substracting this entity type from the layer definition makes no difference (registered layers always fail).

Altering the undocumented (and continually evolving) EFLAGS mask column is not recommended;
you probably shouldn't do this outside of close coordination with Tech Support.

Well yes I'm hopeful this will be done with ESRI's assistance, but since I'm not a customer myself, but rather my client is, it will be difficult to coordinate this. However it is frustrating that layers created through ArcCatalog and by using sdelayer command behave differently without any possibility of altering this behaviour (i.e. switch with sdelayer -o register command).
Just because both Oracle and ESRI (even though Oracle in a far lesser degree than ArcGIS at v9.3.1) can't handle the 3rd dimension correctly it does not mean the geometry is invalid.

[DaliborKusic]

Another update.... It seems the "problem" wasn't with the EFLAGS, but with the OBJECT_FLAGS attribute in the SDE.TABLE_REGISTRY table. If I take my old table (the one that originally did not work), do not change anything, but only copy this attribute from the table that was created using ArcCatalog and overwriting with it the OBJECT_FLAGS attribute of my old table, the geometries display in ArcMap regardless of their "validity" (also no warnings or errors in SDE log files). Unfortunately I have no idea what this OBJECT_FLAGS is besides it is another binary attribute. I simply copied a value of 147463 over my old value of 133. This is not a perfect solution, but it works for now. Will try to reach ESRI's tech support on this. Anybody perhaps knows the structure of this attribute?

[DaliborKusic]

Hopefully the last update:
It appears the bit 17 of the OBJECT_FLAGS attribute has something to do with SDE verifications. After setting this bit, layers show "normally" (no anomalies so far) in ArcMap and no errors are logged in the SDE log files.
So..lets hope this little bit of reverse engineering holds up through stress tests 🙂