|
POST
|
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
09-28-2010
03:06 PM
|
0
|
0
|
670
|
|
POST
|
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
09-28-2010
10:18 AM
|
0
|
0
|
670
|
|
POST
|
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
09-27-2010
07:45 PM
|
1
|
0
|
10372
|
|
POST
|
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
09-27-2010
01:13 PM
|
0
|
0
|
670
|
|
POST
|
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
09-23-2010
09:50 AM
|
0
|
0
|
2416
|
|
POST
|
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
09-23-2010
05:22 AM
|
0
|
0
|
2416
|
|
POST
|
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
09-23-2010
04:09 AM
|
0
|
0
|
719
|
|
POST
|
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
09-22-2010
12:15 PM
|
0
|
0
|
2416
|
|
POST
|
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
09-21-2010
10:58 AM
|
0
|
0
|
1050
|
|
POST
|
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
09-21-2010
07:43 AM
|
0
|
0
|
413
|
|
POST
|
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
09-20-2010
05:14 PM
|
0
|
0
|
1221
|
|
POST
|
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
09-20-2010
06:07 AM
|
0
|
0
|
269
|
|
POST
|
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
09-16-2010
04:54 PM
|
0
|
0
|
351
|
|
POST
|
If your Oracle client is corrupted, an ArcGIS re-install won't address the issue. Try re-installing Oracle first. - V
... View more
09-12-2010
04:27 PM
|
0
|
0
|
791
|
|
POST
|
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
09-10-2010
01:22 PM
|
0
|
0
|
242
|
| Title | Kudos | Posted |
|---|---|---|
| 2 | 10-10-2025 07:28 AM | |
| 2 | 10-07-2025 11:00 AM | |
| 1 | 08-13-2025 07:10 AM | |
| 1 | 07-17-2025 08:16 PM | |
| 1 | 07-13-2025 07:47 AM |