Latest Contributions by VinceAngelo

‎09-02-2015

It is certainly best practice to drop (not unregister) and recreate the view when schema changes are made to the fields from which the view was constructed. If changes are made to a table outside of ArcGIS's ken, it might be enough to just re-describe the table with a connection as the owner (which is what an 'sdetable -o describe' would have achieved, back in the day). Of course, such changes should never be made to versioned or archived feature classes, due to the conflicts that could result. The same describe procedure might work with views, but it's very much dependent on how the RDBMS goes about validating and revalidating views, so the safe bet is to drop and recreate - V

‎08-25-2015

Messages about selection are messages about drawing -- Nothing is drawn if it isn't successfully queried first. Layer metadata includes envelope, coordinate reference, supported entity flags,... The idea is to give us enough information to help find the problem. The level of detail which is likely needed to solve this indicates that you should contact Tech Support. - V

‎08-24-2015

What geometry storage format is used? What entity types does the table support? How many total features in the layer? What layer metadata exists for the table? Are there any messages is the connection/direct connection logfiles?

‎08-24-2015

Due to the way Oracle shared library referencing works, you might be able to register multiple DLLs in the same instance, BUT YOU SHOULD NOT EVER DO THIS! Oracle instances can only be registered with exactly one geodatabase -- There really ought to be only one master SDE geodatabase, but if you do have user-schema geodatabases, THEY MUST BE UPGRADED IMMEDIATELY AFTER THE MASTER GEODATABASE! If you simply have multiple Oracle instances, then each one can have it's own version of ArcGIS, with its own referenced DLLs (the security issues of the LISTENER have removed registration there). The trick here is that there's no documentation on the procedure because it's not formally supported. I regularly ran 6-8 ArcSDE instances of different releases and databases on a single machine, but it's somewhat temperamental (especially at start-up on Windows platforms; cakewalk on Unix), and requires an arcane level of understanding of ArcSDE function. All-in-all, your safest option is to run your geodatabases in parallel release states, and reserve the odd-man-out instance to a test server before upgrade. - V

‎08-22-2015

You are setting yourself up for issues in the future, but it is possible to maintain a simple feature class exclusively from SQL. "Simple feature class" means: Table is registered with ArcSDE with a USER-set registered rowid (sdelayer -o register -C objid,USER...) Feature class is NOT versioned Feature class is NOT archived Feature class does NOT participate in geodatabase behaviors (relationship classes, feature datasets,...) In essense, just a stripped down, native table with geometry (SDE.ST_GEOMETRY or MMDSYS.SDO_GEOMETRY). It's theoretically possible to not trash tables with SDE-set rowids, if you honor all the restrictions in ID allocation, but that would likely tempt you into something which would regularly corrupt your geodatabase. - V

‎08-21-2015

Are all the geodatabase-required pieces added back in to the table? I'm not sure I'm brave enough to give Microsoft carte blanche with my geodatabase integrity. - V

‎08-21-2015

Highly unlikely (it certainly isn't a supported configuration), though the answer may depend on the RDBMS (often the developer framework provided by the RDBMS vendor has a role to play -- e.g., PostgreSQL 9.1, 9.2 and 9.3 are incompatible, even at the same ArcGIS release) - V

‎08-20-2015

Lance told me just yesterday that the File Geodatabase API does not support licensed GDBs (Python and ArcObjects are equivalent in the context of FileGDBAPI.dll). - V

‎08-20-2015

Not without dropping the table and replacing it with a table with columns in a different order. A view can be used to specify column order, but they can't participate in many geoodatabase-centric behaviors. - V

‎08-20-2015

There are a zillion ways to make a table clone, but the easiest is to just CREATE TABLE bar AS SELECT * FROM foo (This of course assumes you have native geometries [MDSYS.SDO_GEOMETRY or SDE.ST_GEOMETRY], otherwise you need to use an export/import mechanism that is geometry-aware.) The RENAME syntax is in the Oracle documentation (I didn't memorize that). (And RENAME use is also predicated on native geometry) - V

‎08-20-2015

The Dn table does not contain business table attributes, only the An does. The root issue here is using database tools on tables registered with the geodatabase. You need to be very careful to avoid corrupting geodatabase metadata (field sizes are maintained in multiple locations within SDE and GDB tables). Best practice is to only use geodatabase-aware tools for these sorts of changes (or unregister versioning, clone the table, drop the table with ArcGIS, rename the clone, alter the clone, then re-register it and re-version it). - V

‎08-20-2015

Versioning is a table-oriented capability, so the numbering of the An and Dn tables is keyed from the registration_id in the SDE.table_registry row associated with the feature class business table. The documentation has the details. - V

‎08-19-2015

Esri does not "encrypt" file geodatabases. ArcObjects supports "compression" of file geodatabases, but this is merely a read-only form (which is passively readable by the 1.4 FGDB API). ArcObjects also supports the licensing of data in file geodatabases; the FGDB API does not support this. - V

‎08-19-2015

ArcGIS 9.2 has been retired for over three years now, and ArcSDE command line tools have not (and will not) ever supported file geodatabase. The task would be easy with a modern release of ArcGIS Desktop (with Python scripting), but it's been too long since I last used 9.2 to begin to say how difficult the task might be. - V

‎08-19-2015

The technology still exists, but it's now just a part of the software framework, not a product (something that can be licensed). ArcSDE is used to implement enterprise geodatabases, but it's not the only component. ArcSDE is not "obsolete", but the API and application server were deprecated at 10.2, and are unsupported at 10.3. A GIS StackExchange answer discusses the evolution in more detail. - V

My Ideas

Latest Contributions by VinceAngelo

Re: How to update fields in a registered view

Re: ArcSDE layers does not draw but can be selected

Re: ArcSDE layers does not draw but can be selected

Re: libst_shapelib.so 10.3 backward comptability

Re: Potential Problems Truncating/Deleting Record in an SDE layer from oracle creating Orphans

Re: Permanently Reorder Fields in Feature Class (SDE)

Re: libst_shapelib.so 10.3 backward comptability

Re: Does the fGDB API support encrypted fGDBs?

Re: Permanently Reorder Fields in Feature Class (SDE)

Re: How to repair an SDE Append and Delete versioning table

Re: How to repair an SDE Append and Delete versioning table

Re: How to find the Add and Delete tables related to a FC?

Re: Does the fGDB API support encrypted fGDBs?

Re: using sdeimport to update an existing SDE layer w/an updated FC

Re: How can I get test environment for ArcSDE

Re: Error Connecting to Enterprise Geodatabase (SQ...

Re: Precision vs. XY Resolution

Re: Best practices for programmatically mirroring ...

Re: Best practices for programmatically mirroring ...

Re: Best practices for programmatically mirroring ...

Coordinate Reference Systems