One to many view woes

1540
22
11-02-2010 07:30 AM
MelissaKrieg
New Contributor III
Is anyone successfully using 1:M views in ArcSDE 9.3.1 and Oracle 10g (10.2.0.2)?

I have been providing several 1:M views to users for years.  They stopped working correctly at SDE 9.2 and now work inconsistently at SDE 9.3.1.  By that I mean that the 1:M relationships show quite plainly as stacked polygons in ArcCatalog, but not in ArcMap.  And also that the 1:M views export incorrectly, i.e a user has 1500 features selected on the view and exports his selection to a shapefile only 500 features export.

As an example, I have a 1:M view where the '1' part of the view is a county feature class, and the 'M' is a table which has one or more rows per county.  In the view, I'm using an OBJECTID field from the M table in order to have a unique OBJECTID for the view.   In fact, all fields are coming from the 'M' table except for SHAPE which is coming from the '1' feature class. 

I've eliminated the following as contributors to the problem:
Oracle client version
BLOB vs. LONGRAW geometry storage
outer join (+) added to 'M' side of business table view post sde command line creation
OBJECTID for view coming from '1' feature class (results in duplicate OBJECTID)

Running traces in the database for views that mysteriously work versus views that do not tells me that an additional select on SHAPE.FID from the F view (see below) seems to make the difference.  But, I have no idea how ArcGIS generates this SQL from the sde view I created.  Does ArcGIS Desktop generate the SQL or does ArcSDE?

You can probably tell from the bind variables at the end of the SQL, but the below was captured from a DB trace while I was in ArcMap and used the identify tool on a county that has 2 records in the many table. 

SELECT /*+ LEADING INDEX(S_ S3060_IX1) INDEX(SHAPE) INDEX(COUNTIES_MAP_STATUS_VW A3060_IX1) */
       objectid,
       st_name,
       cnty_name,
       stcnty,
       agmt_type,
       incomplete_legal,
       arcmap_requested,
       update_requested,
       needs_review,
       polygen_error_general,
       polygen_error_no_grid,
       polygen_error_no_legal,
       polygen_error_no_lot,
       shape,
       shape.area,
       shape.len,
       shape.fid,
       s_.eminx,
       s_.eminy,
       s_.emaxx,
       s_.emaxy,
       shape.fid,
       shape.numofpts,
       shape.entity,
       shape.points,
       shape.ROWID
FROM (SELECT /*+ INDEX(SP_ S3060_IX1) */
            DISTINCT
             sp_fid, eminx, eminy, emaxx, emaxy
      FROM lease.s3166 sp_
      WHERE     sp_.gx >= :1
            AND sp_.gx <= :2
            AND sp_.gy >= :3
            AND sp_.gy <= :4
            AND sp_.eminx <= :5
            AND sp_.eminy <= :6
            AND sp_.emaxx >= :7
            AND sp_.emaxy >= :8) s_,
     lease.counties_map_status_vw,
     lease.f3166 shape
WHERE s_.sp_fid = shape.fid
      AND s_.sp_fid = lease.counties_map_status_vw.shape
...

I'm looking for help diagnosing why our 1:M views no longer work correctly, or help understanding how the spatial view is used by ArcGIS, or to hear from anyone using 1:M views successfully.
0 Kudos
22 Replies
MelissaKrieg
New Contributor III
I've been familiar with ArcObjects' requirements for a unique registered rowid column
since 8.0 went beta. If you look at my view construction commands, both here and in the
old Forums, you'll see that I always take the objectid column from the many side, which
circumvents the Knowledge Base issue. Note that it's not ArcSDE which has an issue
with non-unique objectids -- Desktop has to juggle the relationship between attribute
metadata and graphics in the display pane; without a unique feature key to associate
them, that task becomes nearly impossible.
.
.
.

If a spatial view with a unique registered rowid column doesn't behave properly while using a supported
database build, please bring it to the attention of Tech Support.

- V


Well, I'm pulling the registered rowid column from the many side to ensure it's unique, so it sounds like maybe the Oracle version is my problem afterall.
0 Kudos
VinceAngelo
Esri Esteemed Contributor
Can you put 10.2.0.2 on a different box, populate the tables and view to reproduce the
problem, then upgrade Oracle and try again?  I've found 10.2.0.3 to be *way* more stable
than 10.2.0.2, but since Oracle isn't supporting 10g anymore, you need to be careful with
upgrades (two backups wouldn't be a bad plan).

- V
0 Kudos
MelissaKrieg
New Contributor III
For what it's worth, we finally figured this one out.  The root cause is that my feature class' geometry storage was SDEBINARY.  Once I converted the FC to ST_GEOMETRY, my views work perfectly. 

I had earlier tested converting the SDEBINARY to SDELOB, but that didn't improve things.  So, our SDE admin and DBAs are now creating a plan to convert all of our SDEBINARY and SDELOB to ST_GEOMETRY (which I understand we should migrate to in any case).
0 Kudos