Latest Contributions by VinceAngelo

I'm not sure the prerequisite check validates external (featuredataset) topology, but it does scan for corrupt geometries (the "self-intersecting" message is not due to an optional ArcGIS topology). The data *should* be correct to be inside the database. ArcSDE performs referential integrity checks before accepting features for insertion into the database. If invalid features are present, this represents a serious issue (especially with ST_GEOMETRY, SDEBINARY, or SDELOB storage), which is why Craig urged you to contact Tech Support. The purpose of the 'Prerequisite Check' checkbox is to avoid an undo after the actual upgrade fails because prerequisites are not met. If you run a prerequisite check *only*, find problems, fix them, run another, and the database is clean, *then* you can un-check the box to avoid another long-running check before the actual upgrade starts (this is "best practice" methodology). - V ... View more

It's a bit more exotic than that.  Oracle doesn't directly support ANSI integer and floating-point types, so INT64TYPES was added to allow the server to map the columns of previously undiscovered tables into SE_INT64_TYPE or SE_FLOAT64_TYPE columns.  It will also prevent creation of new tables with SE_INT64_TYPE columns via the ArcSDE API. I'm not exactly sure how it interacts with the PG svrmgr (since PG uses discrete types, not "NUMBER", there's less flexibility in column bind variable types).  I believe the  BIGINT type is simply unsupported without regard to INT64TYPES content (that is, ArcSDE identifies the correct type, but ArcGIS doesn't support it).  You could confirm this by doing a 'sdetable -o describe' on a "new" table -- If the describe fails, then ArcSDE is honoring INT64TYPES=FALSE. - V ... View more

While ArcSDE does, ArcGIS Desktop and ArcGIS Server do not support BIGINT (64-bit integer) datatypes (which is why INT64TYPES is disabled by default). - V ... View more

You can't apply a coordinate reference after the fact when using ArcSDE command-line utilities. The same is not true for spatial index parameters -- you can change them at any time (see the admin doc for 'sdelayer -o alter -g ...' and 'sdelayer -o {load_only_io | normal_io}') If you have a file in SDEeXport format, then you can simply use the '-o create' option, which will restore all aspects of the layer (except DBTUNE keyword, which must be specified or it will default to DEFAULTS). Even if you use command-line tools to load tables, they still won't register with the geodatabase (and be available for featuredatasets, et.. al.), but they will be available as simple featureclasses. - V ... View more

ArcSDE is certified on the "supported" platforms.  This means that extensive testing has been done on that configuration, and is known to work.  There's also a "not tested, but assumed to work" status which usually covers most of the patches above the specified release (unless otherwise noted). It's generally safe to assume that an Update 6, 7, or 8 of a supported release will work, but less safe to assume that Update 1 of the *next* release works.  For the most part, Unix releases are very stable, with working backwards compatibility, but Esri only supports that which they've tested. - V ... View more

If you're using a modern ArcGIS like 10.0, than the problem probably relates to incorrect projection metadata on the layer.  You'll need to provide the projection metadata from the File Geodatabase, as well as the actual coordinate range (X/Y envelope) and ArcSDE layer properties (as reported by 'sdelayer -o describe_long'). - V ... View more

I usually construct my own index commands in SQL, and only register with ArcSDE after everything is to my liking.  There's no law that says you can't drop and rebuild indexes after ArcGIS is done loading... - V ... View more

Table permissions should be set via 'sdetable -o {grant|revoke}'.  This didn't work correctly back at 8.01 when 'sderastool -o {grant|revoke}' was created, but it has functioned since at least ArcSDE 8.2. It's possible that the API no longer supports grants through the raster functions; if it doesn't, then I'll disable the option (I'll deprecate it either way). - V ... View more

LoadOnlyMode(true) doesn't speed up query operations. It's purpose is to drop the spatial index to improve INSERT performance, but while in LoadOnlyMode, the feature class query performance will be degraded (no index). It's possible that toggling load mode (from false to true and back to false) will improve spatial query performance (depending on the fragmentation of the old index), but the ordering of the spatial features inside the table itself (spatial fragmentation) might have a bigger impact on overall draw performance than a stale spatial index (and its impact would be evenly applied to both access APIs). "Draw" performance can also be impacted by unnecessary attribute retrieval (only 'get' the attribute(s) you need for rendering). - V ... View more

There's only two cases where you'll get that message: 1) Coordinate data outside the legitimate bounds of the defined projection 2) Incorrect coordinate reference configuration The work-around is determine which case you've encountered (though I suppose both could be true), and make the appropriate correction. What version(s) of ArcGIS & ArcSDE software are you using?  This used to be a frequent problem before HIGH precision coordinate references were incorporated into ArcGIS at 9.2, but now ArcGIS chooses a standard coordinate reference by projection that safely represents the horizon of every possible value in that projection, with 0.1mm resolution (which is overkill, but I won't go there). It's quite possible that your feature class has incorrect projection metadata.  You'd have to post the bounding box coordinates on your shapefile/geodatabase data and the output of 'sdelayer -o describe_long' on the target layer for us to help you determine that. - V ... View more

The KB doc you posted has links to the troubleshooting steps. - V ... View more

I don't generally work with FGDBs, but the table creation XML includes a data envelope property (look for "Extent" in the .xsd).  You should be able to create featureclasses and featuredatasets with pre-defined extents. - V ... View more

I pre-populate the envelopes of GEOGCS ArcSDE layers with {-180,-90,180,90}, just so I don't have to deal with envelope property updates changing the scale at which ArcGIS displays. - V ... View more

"The way to go" has too many variables for blanket statements.  However, the reason for running the ArcSDE server on the database host (tight coupling) hasn't changed. The main drawbacks are: 1) The ArcSDE instance will consume resources (RAM, mostly) on the database server 2) Since 9.2, you need to license the ArcSDE server host independently You don't hit the licensing issue if you run the application server on the ArcGIS Server host, but then you add the processing load of a different server task (which is similar to the Direct Connect thread, but in a process, which is less efficient).  You need a pretty exotic set of situations for an independent (non-AGS) ArcSDE server to be optimal. I recommend using Direct Connect with SQL-Server for two prime reasons: 1) The client is part of the OS (unlike with Oracle) 2) It's not subject to the non-interactive desktop heap connection limitation You only really need an application server if you have a heterogeneous release situation not covered by Direct Connect. - V ... View more