Content of LAYERS.EFLAGS column

1919
4
04-02-2012 01:19 AM
ChristianKaufmann
New Contributor
I'm looking for a list with constants to extract information from a value of the LAYERS.EFLAGS column. I know the values for the shape type, but this is not complete. Ineed to read the information about storage type, etc. (SDEBINARY, ST_GEOMETRY).

Where can I find this list of constants?

cu Christian
4 Replies
VinceAngelo
Esri Esteemed Contributor
The EFLAGS bitmask values are undocumented, and change from release to release.
If there was a list of constants it could be four billion values long.

The information for which you appear to be looking is available elsewhere -- If a layer
is ST_GEOMETRY it will be in the SDE.ST_GEOMETRY_COLUMNS table, and the
SDE.GEOMETRY_COLUMNS table has a STORAGE_TYPE flag (though as a rule, it's
safer to use rows instead of undocumented fields).

- V
0 Kudos
BrandonNelson1
New Contributor III

If there was a list of constants it could be four billion values long.

Then the field is poorly named, because that's an enum.  😉

Even allowing a 64-bit field (though it appears to be used as 32-bit) and some grouped bits for e.g. feature type, I'd expect there's less than a hundred. 

As a database admin, I'm with Christian that this information, even read-only, could be extremely helpful to analyze and troubleshoot our geodatabase.  Time to put on my engineer hat backwards, I guess….

0 Kudos
LarsNordvall
New Contributor II

Yeah, and because the eflags are undocumented we can only hope for the best when setting this field with sql. And yes we need to.. because registering an empty table registers result in a 2d FC. One workaround would be to insert one 3d geometry in the table before registering, but come on! NO! Another would be using Z and M geoprocessing environment settings in the register tool. 

ESRI, please document your product!

VinceAngelo
Esri Esteemed Contributor

Directly modifying rows in the SDE-owned tables outside of the stored procedures invoked by ArcObjects is very unsupported. Even if the existing flags were documented, the only supported use would be for read-only metadata purposes. All other uses are likely to result in geodatabase corruption (in the post-9.x denormalized implementation, metadata is redundantly stored for performance optimization; if you miss even one location, integrity is compromised, which could cause upgrade failure years later). I suggest you contact Tech Support for a less risky procedure.

- V

0 Kudos