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….
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!
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.