Latest Contributions by VinceAngelo

Given that base64 MIME encoding is going to increase file size by 1/3, it's probably wise to always zip before e-mailing data (including .mdb files) -- this will also give you a way to detect corruption in transfer. The one file solution has a drawback as well -- File geodatabases do not have any real size limitation, while PGDB are limited to 2Gb. - V ... View more

ST_GEOMETRY doesn't have triggers like SDEBINARY and SDELOB, though I'm sure there's an equivalent within the object behavior (one that's not subject to external tampering). - V ... View more

ST_GEOMETRY does not have F or S tables, so it's not just the triggers that are missing. There is an S table analog, but the F table is implemented as a LOB object type in the business table (see the online doc for ST_GEOMETRY storage architecture details). - V ... View more

Shapefiles suffer from a number of defects, most related to the limitations of dBase: 1) Lack of numeric NULLs 2) Lack of second precision on date types (limited to YYYY-MM-DD) 3) Column name clipping at 11 characters 4) 254 character limit on strings (and lack of NSTRING, and fixed width transfer) File geodabases have none of these issues. For consistency's sake (with either format), you should be transferring zipfiles, not individual file components. - V ... View more

There are several storage methods possible with ArcSDE, not all of which are available on all database platforms. The only significant change between 9.2 and 9.3 was a change to the default storage type on Oracle 9i/10g from SDEBINARY to ST_GEOMETRY. You have always had the option of specifying storage location (via DBTUNE file, which every site should modify for their environment). Default storage type is also a property of the DBTUNE file. There are multiple copies of this documentation online via a Resource Center search (UR search window); the most recent of which is avaliable here. Placing custom triggers on ArcSDE-managed tables is unsupported, and moderately risky. You'd be much better off using the DBTUNE mechanism for storage management. - V ... View more

I always manage permissions by role (create a role, grant table access to the role, grant the role to users), so editing access through users would make my life much harder, but if you don't have any roles, then you could do it that way.  You might need to revoke all access first, just to clear the previously granted access. - V ... View more

I generally manage permissions through roles from creation scripts, so I know exactly what permissions should exist on each table.  Exploring this from the database side is a rather involved task; I would need to review the entire database security architecture, consult experts (as found in a database vendor's forums), and then once I had the database matrix of tables/users/roles/permissions, I'd need to reconcile that with feature datasets and ancillary/support tables.  It's not an impossible task, but it is likely to be tedious and painstaking. 😞 Good luck. - V ... View more

It's common to see "table does not exist" errors during initial creation, since it's best practice to check if something already exists before creating it.  SQL doesn't generally have an "exists" function, so you query permissions and let the "table not found" error stand as an answer.  It's perhaps misleading to use a single error-handling function when you *expect* an error, but we're just talking about a setup log, after all. - V ... View more

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