Latest Contributions by VinceAngelo

Even if you have the list of users, you'd still need to know the passwords of each to have the database report permissions though ArcObjects or ArcSDE.  So you'd need to use database techniques to obtain this, as Rob's post suggests. - V ... View more

Does the SDEHOME variable have a trailing slash? The fopen() function ignores duplicate intermediate slashes, so this isn't likely the problem. 'shp2sde' isn't supported with Workgroup ArcSDE, but I doubt that's the issue either. "125212" isn't a valid codepage ("1252" is) which I expect *is* the issue. Have you explicitly set a variable for codepage encoding? Do any of your environment variables contain "125212"? This messge is a warning -- do you have codepaged strings in the source shapefile? If not, then you can probably ignore this message. - V ... View more

Databases have an inherently "flat" organization. This is one of their strengths, since there are significant performance benefits to not being able to "lose" a table in an arbitrary folder organization. Esri honors this external design constraint with the ArcSDE interface -- there is just one SE_table_list() function. Therefore, you have three sources of control: + Database instance + Database user (schema) + Table name Feature datasets should only be used to manage objects which will be edited togther (even though it is common, there are serious penalties for using FDS as a simple folder). Since Oracle doesn't have a "multi-database" paradigm, Esri engineered "schema geodatabases" to isolate all the tables for a given user within an instance. Using this construct can also mean more connections, since accesses to the different schemas all require their own connections. I generally use table owner to reflect the provider or geographic extent, then use underscores to partition the name by theme (and I tack on the map scale and geometry class as suffixes): C:\Temp>  sdelist -o table ArcSDE 9.3 Table Listing Utility         Tue Sep 21 11:28:48 2010 ------------------------------------------------------------------------ eval93.europe.admin1_100k_a eval93.europe.cities_100k_p eval93.europe.country_100k_a eval93.europe.rail_100k_s eval93.europe.railstations_100k_p eval93.europe.roads_100k_s eval93.usa.admin1_100k_a eval93.usa.admin1_1m_a eval93.usa.admin2_100k_a eval93.usa.admin2_1m_a eval93.usa.airport_100k_p eval93.usa.cities_100k_p eval93.usa.cities_1m_p eval93.usa.hydro_100k_l eval93.usa.hydro_1m_l eval93.usa.rail_100k_l eval93.usa.roads_100k_l eval93.usa.roads_1m_l eval93.usa.roads_500k_l eval93.world.admin1_100k_a eval93.world.cities_1m_p eval93.world.country_100k_a eval93.world.country_5m_a eval93.world.gazateer_100k_p eval93.world.nightlights_5km eval93.world.wsi_earth99_4km 26 tables found - V ... View more

If you check your service properties, you might find that the "path to executable" is invalid. I almost never use the -H option, because I always explicitly set SDEHOME and PATH before invoking 'sdeservice': set SDEHOME=D:\ESRI\arc100sql32-sp0\ArcSDE\sqlexe set PATH=%SDEHOME%\bin;%PATH% sdeservice -o create ... I also avoid spaces and special characters in my SDEHOME directories, even though it shouldn't make a difference (old habits...) - V ... View more

I regularly partition data by schema to manage access, but never do solely on the basis of spatial/non-spatial (I'm not sure if I really accept that there *is* non-spatial data, vice explicit and implicit spatial data). An ArcSDE 8.3 -> 9.3.1 "upgrade" isn't really possible (without several intermediate steps), and 9i and 11g are sufficiently different that a fresh reload is likely your best migration path. If you have versioned tables, preserving the versions during migration will be quite challenging. The same goes with complex geodatabase behaviors and, to some extent, rasters. If you have all simple non-versioned vector featureclasses at 8.3, then 'sdeexport' is your easiest transfer methodology (you'll need to read up on storage method options for 'sdeimport', since SDEBINARY is not available on 11g platforms).  All other transfers would require more input (including which versions of ArcGIS you have available to support incremental upgrades via personal geodatabases). You might be jumping the gun on 11gR2 support at 9.3.1 (10.0 is certified with R2 on more platforms than 9.3.1), so you probably want to make sure it will work with 9.3.1 on your platform before you proceed. - V ... View more

I doubt this is JPEG2000's fault.  Instead look to your tile size -- 8192x8192 is *way* too large. The *compressed* size of a single tile shouldn't exceed 8-16K; starting from 64Mb (assuming 8-bit data) is not the way to get  there. You can see how large your tiles really are by doing a SQL query like --      SELECT avg(datalength(block_data)/1024) AVGkb FROM SDE_blk_23 Generally speaking, anytime you need to increase the default 2Mb RASTERBUFSIZE giomgr.defs parameter you will usually hurt raster performance.  I use 96x96 tiles with LZ77 compression, and let the 128x128 default stand with lossy (no more than 256x256 with heavy compression). - V ... View more

If your Oracle client is corrupted, an ArcGIS re-install won't address the issue. Try re-installing Oracle first. - V ... View more

The envelope does not limit the range of future features.  You should be using the "-x" flag to specify the x/y coordinate reference, which does control what features can be added. - V ... View more

Windows generates a "file not found message" when a DLL search returns the wrong bit-size library.  Is your Oracle 64-bit?  If so, you'll need a 32-bit install for ArcGIS.  If 32-bit is installed, does it come *before* 64-bit in the PATH variable? Make sure you've got SP2 installed, or you may run into an issue with 32-bit and 64-bit connections on the same server. Those of us without Word on our home PCs would be able to see a JPEG or PNG attachment. - V ... View more

Domain and extent are very different things.  The extent of a layer can always be adjusted, usually through the use of 'sdelayer -o alter -E minx,miny,maxx,maxy'. The domain (coordinate reference) can never be adjusted, since it defines the origin of the encoded shapes. - V ... View more

What database product are you using (are a least half a dozen SQL-supporting databases that also support spatial types)?  On what platform? There isn't any way to predict the performance of native types across products or platforms, or even in differing storage format on the same product/platform.  Even the same storage format can give wildly different performance, depending on the nature of input data, order of execution and tuning parameters. - V ... View more

It can't be a known issue until an incident is filed with Tech Support.  Unfortunately, it's now too late to get the fix(es) into 9.3.1 SP2 or 10.0 SP1. It won't be as efficient as a server-side function, but you can write your own helper to fetch all the shapes meeting your critera, then return the envelope.  Be sure to pass in *only* the geometry column -- se_layer_calculate_extent(SE_CONNECTION conn, char *table, char *column, char *where,                 SE_ENVELOPE *e, LFLOAT zrange[2], LFLOAT mrange[2]) Note that this is close enough to  SE_layer_calculate_extent that you can try this function as well. If you're using ST_GEOMETRY, then there's probably a pure SQL call which will return the union of the shape envelopes for a where clause (which would be less expensive than the current SE_stream_calculate_layer_extent).  ArcSDE 10.0 has a new SE_EXTENT_STATS_QUERY object API, but no documentation, so it may not be implemented yet. - V ... View more

I'd still recommend using the -R or -x & -G flags when registering a table with ArcSDE, especially when you consider that the coordref generated without them can't represent all data in the envelope you specified (which should probably be reported as a bug). - V ... View more

Direct Connect is going to log to the SDEHOME from which the connection is made; if you decentralize your connections, you also decentralize your connection logs. That message may just be from a 'sdesetup -o upgrade', which uses Direct Connect locally on the server. - V ... View more

I found the magic search term that led me to the right directory for OCI include files: 8 = SQLT_LNG             /* long */ 23 = SQLT_BIN             /* binary data(DTYBIN) */ 187 = SQLT_TIMESTAMP     /* TIMESTAMP */ 188 = SQLT_TIMESTAMP_TZ /* TIMESTAMP WITH TIME ZONE */ 190 = SQLT_INTERVAL_DS  /* INTERVAL DAY TO SECOND */ So, we've got two generic binary types and three time types with no mapping to the supported ArcSDE type list. You may be able to use a customized view to remap those types to something that ArcSDE will know how to decode. - V ... View more