topic Is the key to OBJECT flags somewhere on the documentation. in Data Management Questions

Is the key to OBJECT flags somewhere on the documentation.

OvidioRivero — Mon, 04 Apr 2011 19:10:37 GMT

I am trying to find what each of the codes for the OBJECT_FLAGS column in the COLUMN REGISTRY table mean. The documentiation does not seem to have the codes it only states the following:

Stores the column properties, which include the following:

Has a row ID
Row ID column controlled by ArcSDE
Allows NULLs
Stores Oracle LONG RAW data
Stores BLOB data
Stores CLOB data
Stores ST_Geometry geometry data
Stores binary geometry data
Stores user-defined type geometry data
Stores Oracle LOB geometry data
Stores binary raster data
Stores user-defined type raster data
Stores XML data
Stores dates
Stores time
Stores a timestamp
Stores a Unicode string

But where can I find a key to the codes?
Any help is greatly appreaciated. Thanks,

Re: Is the key to OBJECT flags somewhere on the documentation.

VinceAngelo — Mon, 04 Apr 2011 20:08:28 GMT

I doubt the bit masks in OBJECT_FLAGS are meant for public consumption. I know the
meaning of the LAYERS flags have evolved over time, so you'd be setting yourself up
for a nasty case of "I just upgraded and my app no longer works".

- V

Re: Is the key to OBJECT flags somewhere on the documentation.

OvidioRivero — Tue, 05 Apr 2011 12:42:46 GMT

There would not be programmers without tweaking and prodding into applications and databases...

I'll stay off that table as you recommend. Then I have to ask another question. I have a large feature class where I want to remove a not null constraint. This is very easy to do at the database level. Can we somehow do it in ArcSDE or do it in the database and make ArcSDE see it? I am trying to avoid reloading all the data only to accomodate a small subset.

Re: Is the key to OBJECT flags somewhere on the documentation.

VinceAngelo — Tue, 05 Apr 2011 14:28:00 GMT

Tweak and prod at will. Just keep in mind that bitmasks are the most likely means of
implementing subtle changes in behavior between releases, and are therefore least
likely to be reverse-engineered safely. Read-only is the safest use of a bitmask, but is
still not without risk (mostly errors of omission).

There are three ways to access spatial data through ArcGIS:
+ Via ArcObjects
+ Via the ArcSDE API
+ Via SQL

ArcObjects uses ArcSDE uses SQL, so the safest way to manipulate database objects
registered with ArcGIS is AO. Simple feature classes which are only registered with
ArcSDE are safe to manipulated with ArcSDE, and databse objects which have not been
registered with ArcSDE are safe to be manipulated with SQL.

Nothing in the ArcSDE data model addresses constraints, but ALLOWS NULL/NOT NULL is
a fundamental column property. Both the ArcSDE API and the 'sdetable' command allow
alteration of the allows_null property. If the table is registered with ArcGIS I'd recommend
using ArcGIS to make the change, otherwise 'sdetable -o alter_column -x ALLOW_NULLS -t ...'
will make sure that ArcSDE sets the correct bitmask in the columns table.

Altering tables through database interfaces is a common part of spatial database
maintenance, though some alterations are riskier than others (especially with regard
to versioned tables). Since, in the end, most of ArcSDE is implemented as SQL, most
anything you break can be fixed again (just make sure you have a verified backup/
recovery procedure and a fresh snapshot before you venture into unsupported realms).

It is also important to keep causality in mind -- changing the bitmask flag which
indicates a column's 'allows_null' property does not change the target column's
null behavoir in the database. This option should only be pursued if an 'sdetable
-o describe' as the owner reflects different information than a DESCRIBE does
(and it still might not alter ArcGIS's interpretation of the same column). The few
times I've needed to hack the column registry, I usually wound up reloading the
table anyway, making it a moot exercise.

- V