Latest Contributions by VinceAngelo

Note that I wrote "if you want to reorganize ... using DBTUNE ..."  There is nothing stopping you from using database tools to reorganize individual poor-performing tables.  Oracle doesn't support clustered indexes the way other RDBMSes do, so you'd need to look at shutting down your ArcSDE server, and exporting and reimporting tables with alternate storage (and then restarting ArcSDE).  I've frequently done this sort of reorganization when "upgrading" an older server to a new one, by using 'exp rows=N', then 'imp indexfile=path' and editing the DDL to change the TABLESPACE name to one with UNIFORM extents more in line with actual utilization.  Of course, there are many ways to accomplish the same task, including use of CREATE TABLE foo TABLESPACE bar AS SELECT ... (but be sure to create all the same indexes with the same names and transfer all the triggers, etc). Using these techniques is of course unsupported by Esri, but there is little risk if you have a full (and validated) backup before you start and recreate the table exactly. - V ... View more

ArcView cannot edit ArcSDE datasets.  You must have an ArcEditor or ArcInfo class seat of Desktop to read/write access to ArcSDE.  If you have a licence available you can use Programs->ArcGIS-> Desktop Administrator to change your active Desktop license. - V ... View more

If Tech Support says the geodatabase creation code is not publicly exposed, then I believe them. - V ... View more

I'm not sure how you got that to work before, since the "SRID" of SDO_GEOMETRY and "SRID" associated with ArcSDE layers refer to completely different things -- Esri SRIDs have always been sequence-based, while Oracle SRIDs have always been lookup-table based (Oracle's SRID is a lot closer to Esri's projection engine EPSG coordinate system factory code, while an Esri SRID refers to the entire coordinate reference, including coordinate system, precision, and X/Y, Z, and M false origins and offsets). The Esri SRID associated with a feature dataset can always be determined through looking at the SRID value in the LAYERS or GEOMETRY_COLUMNS table for the layers in that dataset. - V ... View more

You can't alter the keyword associated with a raster, and though you can alter a layer's keyword, it will not change its storage. The layer config keyword stored in LAYERS, TABLE_REGISTRY, and RASTER_COLUMNS just represents the storage rules at the time the layer was created. If you want to reorganize data for better performance using DBTUNE, you'll need to export the data, change the existing keywords, drop the existing tables, and reload them. The only exception for this is some of the indexes, those which can be rebuilt by placing a layer in load-only I/O mode and back into normal I/O, or those manually created by 'sdetable -o create_index', which can be deleted and rebuilt. If I have a minor typo in my DBTUNE environment, I'll often edit the keyword to be correct then REBUILD the indexes maually at the SQL prompt, but if table storage is wrong, I have to delete and re-load. - V ... View more

All ArcSDE software installations have a "tools" directory where RDBMS-specific scripts are maintained.  The exact requirements change from release to release, so you really shouldn't be using an older script without cross-validating with the scripts under tools. - V ... View more

And on what OS platform are you operating? There is no way to extract the SDE user password from ArcSDE or the Windows service, but since Unix doesn't use a Windows service, the boot script may contain the password. Your only real "recovery" process is to delete the service, change the password from SQL, and restablish the service (via command-line or "custom" post-Install GUI step). - V ... View more

Personal and Workgroup ArcSDE have C# hooks in ArcObjects, but Enterprise ArcSDE requires the use of 'sdesetup' and 'sdeservice' utilities.   You can wrap them, but the level of artificial intelligence to handle common troubleshooting would add man-years to the effort. - V ... View more

The SDE user password really shouldn't be present in *any* map documents. As an administrative management account, the SDE user should not own spatial data, and the password for it should be closely held (to limit the possibility of instance corruption). Best practice calls for data ownership accounts to manage spatial data, and browse accounts for read-only access to data that doesn't need editing (and read-mostly access to data which may [granted through roles]). You'll still have an impact from browse user password expiration, but if it really is read-only, there won't be as pressing a reason to enable time-based expiration. Some sites require users to log in as themselves for browse accounts; you can support this by not storing the browse user password in map documents (uncheck the "save password" tic-box), which allows users to override the username and password at initial connect. OS authentication can also help in this regard. A forums search (lower box in upper-right corner) on "mxd password change" brought up several posts that lead to resources for changing broken map documents, but you may need to review current geodatabase implementation before you can make best use of them. - V ... View more

There is a known issue with Oracle 11.2.0.2 and versioned SDO_GEOMETRY layers. No solution has been published, hence you should look for one in the future. - V ... View more

In order to get ST_GEOMETRY available through non-ArcGIS clients, you'll need to install at least the ArcSDE libraries on the listener hosts; installing ArcSDE is optional but recommended. With Direct Connect a possibility from clients (recommended to RAC servers), there is no requirement that an ArcSDE application server be installed, though if you have an ArcGIS server host, then I'd recommend you install ArcSDE for an application server there (it helps with install management). Most 10.x upgrades are done through ArcCatalog, so the location of ArcSDE is less critical. Keep an eye out for the hotfix for 11.2.0.2 support. - V ... View more

It looks like your indirect layer creation process has corrupted the layer metadata.  I suspect the register command didn't create an index because the metadata indicated one was present. I'd recommend you go through the exercise of defining an appropriate grid size, since your previous spatial index had all but one of the features in a single grid tile.   This will also correct the "yes, you have no index" situation. - V ... View more

No, all data in any single table must be in *one* projection. You must reproject all data into a common projection. - V ... View more

UTM zones exist because, once you get toward the edges, the error becomes unacceptable for high precision tasks.  There is still room for lower precision tasks ~2-3 degrees into the neighboring zone, but you might be better off using an Albers projection which covers your area of interest properly.   I don't recommend you split your data across two different zones, then try to align them on the fly. - V ... View more

'sdelayer -o si_stats' does statistics on the Sn table, which doesn't exist with ST_GEOMETRY storage. What does 'sdelayer -o describe_long' report? What command did you issue to create the index that can't be found? - V ... View more