Latest Contributions by VinceAngelo

ArcGIS requires that ArcSDE layers have unique objectid values.  When you construct a one-to-many view, you risk breaking that requirement if you are not careful. There are two solutions: If you have ArcEditor or ArcInfo you can create a relationship class to manage the 1:M relationshp outside a view, or you can create a view that preserves the objectid uniqueness requirement by adding a USER-set or SDE-set objectid column on the many side, and referring to that in the create_view column list. - V ... View more

The OGC intent was certainly to permit subqueries, but there's still the SRID issue with which to contend. A Microsoft forum would probably be a better place to find experts on GEOMETRY behavior in SQL-Server 2008.  ArcSDE just uses an envelope search as a filter and then uses Esri's libraries for topological comparison (whether it's GEOMETRY/GEOGRAPHY, ST_GEOMETRY, SDO_GEOMETRY,  PG_GEOMETRY , SDEBINARY, or SDELOB storage).  Shape library comparisons are done at the precision specified by the layer coordinate reference (inverse of xyscale). - V ... View more

That behavior is by design, to reduce clutter.  The other schema's tables might just be feature datasets (owned by other users, but not accessible because one or more of the tables within are not SELECTable). - V ... View more

The ArcSDE 'C' and Java SDKs are on separate media, which can be ordered through Customer Service. - V ... View more

What platform are you using? Which version and service pack of ArcSDE are you using? Do you have the Java ArcSDE SDK installed on the client? - V ... View more

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 ... View more

The POLYGON constructor accepts an SRID, but the ArcSDE SRID and Microsoft SRID might be different values.  You need to use the Microsoft SRID in the native OGC operators. The ArcSDE sequence-generated SRID is a link to a row in the spatial reference table, where the native SRID resides. - V ... View more

Microsoft's documentation states: This method always returns null if the spatial reference IDs (SRIDs) of the geometry instances do not match. You didn't show the SRIDs involved, but that's the most likely cause. - V ... View more

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 ... View more

If you had been using the single database model, it probably would have been as simple as detach, copy, reattach (this isolation is one of the critical benefits of that model).  The inability to rename databases becomes a key factor when trying to prepare for such transfers. - V ... View more

I've done some pretty exotic things to transfer large rasters in the past, including a months long copy job over a slow an unreliable network link, but none of them involved 'sdetable' for managing rasters.  It may be theoretically possible to use database tools to transfer the raw binary data, but I've never been forced to try. Using modern hardware, I did a full-on copy of a terabyte of JPEG-compressed (15-25Tb transfer) in under 40 hours.  For 200Gb, you may just be better of copying with a drag-and-drop approach. - V ... View more

You *really* don't want to rename databases -- Doing so corrupts all the fully-qualified database object references generated by ArcSDE (sde_* table metadata is just a trivial part of the problem). This is why renaming databases is unsupported by Esri. If you want to create new single-database model ArcSDE instance databases, you can name them appropriately, then copy the data from old to new. (UNSUPPORTED RISK="MediumHigh") In the past I've run both single and multi-database model ArcSDE instances in a single SQL-Server instance, but the only way I could get it to work was to shutdown the multi-database service, detach the 'sde' database, do my new instance management, then re-attach 'sde' and re-start its application server process. (/UNSUPPORTED) - V ... View more

The purpose of query layers is to view native geometry tables without installation of and registration with ArcSDE.  I'm not even sure that you can change the default storage in Express databases (Personal and Workgroup don't have the same range of functionality as Enterprise ArcSDE), and if you didn't, then the SDEBINARY geometry storage would not be visible to the Query Layer interface as anything but an integer.  It sounds like your install is working according to design. - V ... View more

What geometry storage type(s) are you using? - V ... View more

Using DELETE won't free the high-water storage for those tables.  You can either TRUNCATE or DROP them (they'll get recreated in either the default tablespace or according to DBTUNE storage rules). - V ... View more