Latest Contributions by VinceAngelo

You don't give enough details (which Oracle?, what type of replication?) to give a complete answer, but I do know that you can't run an ArcSDE service in an instance which is replicated by a logical Data Guard configuration. Generally speaking, advanced database configuration and ArcSDE  application servers are incompatible -- Using Direct Connect connections will always be your best solution when RAC is involved. There's little reason to use multiple logins on Unix hosts -- they are not subject to the same limitations found in Windows servers. I regularly run three to five instances of different versions of ArcSDE on Linux boxes with a single UID. The only difficult part is setting up '.profile' configurations for each instance and being sure to run the right one before starting each service. - V ... View more

Direct Connect was created to avoid the issues created by trying to run multiple application servers from a single instance. Note that running a pair of servers may require twice the ArcGIS Server licenses. - V ... View more

You can't use Catalog to change an ArcSDE coordsys (can't use an ArcSDE command-line or API function to do it either; once set, it's immutable).  The Oracle WGS84 string is different than the projection engine WGS84 string, and ArcSDE overrides the PE string when it registers an Orace layer with an SRID. Your only chance to have ArcSDE use the PE WGS84 is to initially define the Oracle table via SQL without an SRID, register the layer with ArcSDE (with the -G or -R flag), then alter the USER_SDO_GEOM_METADATA to include the SRID.  If this doesn't work, then you can go the other way, and define all your ArcGIS layers to use the -R of your SDO_GEOMETRY layer. - V ... View more

There is no ArcSDE command to report storage of database objects.  Instead you must use database tools to determine this information. sp_space_used will report the storage of a table for SQL-Server, but you need to identify the correct associated table (in the form SDE_blk_{n}, where {n} is the rastercolumn_id value from sde.SDE_raster_columns table for the table_name associated with the raster). There are other tables (and indexes) as well, but the BLK table generally holds 99% of the overall allocation.  Vector storage determination is trickier, since the three primary tables are more nearly equal (except when you have thousands of vertices per feature), and versioning makes the problem more complex (two more tables, which may be either small or large, depending on your versioing state tree).  The 'sdetable -o describe_reg' command will identify the tables which participate with a business table in storage of spatial data, but you may then need to determine the indexes of each table. Finally, you need to consider high water marks, since storage isn't generally released after a delete operation (on the assumption [by the RDBMS] that the table will grow again anyway).  Other databases also incorporate "extent" (or "chunk") management overhead so that even a 10Kb LOB might use hundreds of Mb.  Then there's block overhead on the disk drive,...  All in all, it's a rather complex issue. - V ... View more

Try driving your view from the many side - ... -t COUNTIES_MAP_STATUS_DATA,BOUNDARY.COUNTIES_TOBIN ... This may impact spatial query performance, though. Dealing with an incorrect coordinate system is a very complex issue. Your first task is to determine what the proper coodsys of the source data was, and whether the data has been reprojected from that. There may be Clarke 1866 data around, but it isn't common (or precise, or accurate, especially for applications outside the continental United States). Your code *is* using the supported environment variables (except for SDEPASSWORD); it's just cluttering the script to include "-i %SDEINSTANCE%" when SE_connection_create will use the contents from SDEINSTANCE if no -i flag is specified. The easiest way to have types map correctly is to define width limits at column creation ("NUMBER(1)"). Correctling this after creation is possible, but difficult (and if you hack the COLUMN_REGISTRY table, unsupported). - V ... View more

It certainly wouldn't hurt to use the supported Oracle release, but I'm not willing to assign "cause" status until the problem goes away. The only obvious thing I see is the use of an alias for the shape column.  ArcSDE has a history of not handling aliases on the geometry column, so I'm more likely to structure my view with: f=nga_geonames_feature_p_3 n=nga_geonames_name_3 sdetable -o create_view -T nga_geonames_name_p_v3 -t %n%,%f% ^     -c %n%.objectid,%n%.ufi,%n%.uni,%f%.shape... ^     -w "%f%.ufi = %n%.nfi" The projection defined on your layer is the "no projection defined" GCS from Arc/Info days.  Since no one really used that projection for anything, especially global mapping, you probably want to do some research to determine the actual datum used. If the SDEUSER/... environment variables are defined, there's no real reason to specify the -u/-i/-p/-s flags on your command directives. It probably wouldn't hurt to alter the layer envelope to -180,-90,180,90. Do you really want your flag variables defined FLOAT64,38.10 when you could map them to just about any type, including INT16,1? - V ... View more

It would help if you posted the 'sdetable -o describe' output for the '1' and 'M' tables, plus that of the view, and also posted the 'sdelayer -o describe_long' output for the layer and the view.  What command did you use to create the view?  Have you tried deleting and recreating the view? Note that Oracle 10.2.0.2 is not supported with ArcSDE 9.3.1 -- the minimum supported release is Oracle 10.2.0.3. - V ... View more

The only ArcSDE 9.1 that supported 10g was the "ArcSDE 9.1 for Oracle 10g" from the online downloads. In addition to ArcSDE 9.1 being retired, Oracle 10gR2 is *also* retired. - V ... View more

Exactly.  My friends over in Tech Support aren't happy when I lead folks by hand into Unsupported Territory (and you'll notice I'm not a willing guide), but if you can find the road yourself, then you're not likely to need to call Tech Support. The supported mechanism is to establish a test server, load software there, transition your install to 10, then post it back to the production server.  But some production servers are beefy enough to support a bit more, which is how we found ourselves in this mess. Keep in mind that nothing I've posted on this topic addresses the issues surrounding licensing.  You still need to adhere to your license agreement with regard to number of server-CPUs, and the supported mechanism of using a different server to run the 'sdesetup', and not installing a service for the new instance (using only Direct Connect), is far more likely to fit in the licensing model as-is (but you'd need to speak with your local Esri office to clarify any of that). - V ... View more

I'm not really sure what you mean by clarify. I regularly need to run the same versions as my clients, so I'll have 9.2, 9.3, and 10.0 releases on the same machine. As long as the services are created correctly with the 'sdeservice' command, there's no technical reason to prevent this from happening. - V ... View more

There's no problem running multiple ArcSDE instances on the same server (I always have between three and five instances on any host), but when using Oracle, you need to create one database instance per ArcSDE server. Actually, I take that back -- There is a problem: You can't install ArcSDE 9.3 and ArcSDE 10.0 on the same server. This has been covered in this forum repeatedly. - V ... View more

I regularly load five and seven million row GeoNames tables into a number of different RDBMS instances (Oracle 10g & 11g, SQL-Server 2008 & PostgreSQL). Each of these tables uses several GB on disk.  I've never seen the behavior you are describing.  Have you tried to use a direct loader like 'shp2sde' to load the shapefile? Have you tried appending the 1m source data until it fails? Have you tried loading a gigabyte of strings into your PG instance using SQL (without any geometry at all)? Did you use the PG838 that ships with ArcSDE 10? Please open a Tech Support incident, since they're going to be your best resource for determining what's going on.  Be sure to provide all the tuning parameters and complete information about your PostgreSQL instance, since this seems to be the most likely issue. - V ... View more

'sdetable' only supports tables, not feature classes or feature datasets.  It just so happens that feature classes are modeled as tables, so 'sdetable' can be used on feature class names, but feature datasets are not modeled as tables, so you can't refer to them at all with 'sdetable'. If you fail to grant the same permissions for all the tables comprising a feature dataset, ArcGIS will only acknowledge the minimum permission held in common (logical AND), even if that means no permission at all. All in all, you'd be better off using Python (if it has the requisite hooks at 9.3.1, which it likely does; I just don't use ArcGIS all that much). - V ... View more

In theory, there is no difference between using 'sdetable' and 'sdelayer'.  I use 'sdetable' because it is the proper context (permissions are a property of a table), and because I don't need to know the geometry column name, and because it's less typing.  It is possible that using 'sdelayer' could, by design, fail to set raster support table permissions if both SE_SHAPE and SE_RASTER columns existed in a table (I would hope it wouldn't, but I only use 'sdetable', so I wouldn't know).  'sdelayer -o grant' should have been deprecated at 8.1 and eliminated by 9.0, but doing so would have broken a lot of scripts. - V ... View more

None of the ArcSDE command-line utilities will access any of the geodatabase extensions like domains or feature datasets (implemented outside the ken of ArcSDE).  You can use Python to script geodatabase management via ArcGIS (more so at 10.0 than with earlier releases), or manage the indiviual dataset member tables via 'sdetable -o grant'. - V ... View more