Sdo_relate()

Hi, everyone
case: oracle 10g, *sqlplus to call spatial database operator sdo_relate(). And it shows up: Ora-29902: error in executing ODCIIndexStart() routine. Does anyone know how to fix this?
TIA

Hi,
Can you post spatial index creation statement and spatial query you are executing? Also, have you looked through this thread: SDO_RELATE ERROR
Regards,
Andrejus

Similar Messages

SDO_FILTER and SDO_RELATE combined in the same query

Is it possible to combine these two operations?
I have a query that ideally should use SDO_RELATE for polygon data (some 25 million records). However it takes too long to run.
For curiosity's sake I tried using SDO_FILTER and again this takes hours. Again for curiosity's sake I combined the two and records are returned in about 2 mins. Please see the query below (to simplify matters I have used point data).
SELECT
FROM
table t
WHERE
MDSYS.SDO_RELATE(
t.geometry,
MDSYS.SDO_GEOMETRY( 2001,
null,
MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
null,
null
'mask=anyinteract querytype=WINDOW'
) = 'TRUE'
AND MDSYS.SDO_FILTER(
t.geometry,
MDSYS.SDO_GEOMETRY( 2001,
null,
MDSYS.SDO_POINT_TYPE( 501900, 308000, null ),
null,
null
'mask=anyinteract querytype=WINDOW'
) = 'TRUE'
As I see it, in this case SDO_FILTER is doing the primary filtering part. SDO_RELATE is doing primary filtering again followed by secondary filtering the resulting data which is why it is quicker. The data does appear to be correct.
Now am I barking up the wrong tree? Whether I am or not, why is this combination faster than individual use? I would appreciate any thoughts on this please.
Cheers guys
James

something else is going on, although without seeing the real query it is hard to know.
SDO_RELATE is a supoerset of SDO_FILTER. With SDO_FILTER and index query is done, with SDO_RELATE an index query is done, then the relate is done on the geometries returned by the filter query.
What kind of index are you using?
What version of spatial are you using?
Can you post the query window?
Are your geometries valid?

Not using Index when SDO_RELATE in Spatial Query is used in LEFT OUTER JOIN

I want to know for every City (Point geometry) in which Municipality (Polygon geometry) it is.
Some cities will not be covered by any municipality (as there is no data for it), so its municipality name should be blank in the result
We have 4942 cities (point geometries)
and 500 municipalities (polygon geometry)
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'The explain plan for this query is:
SELECT STATEMENT
FILTER
    Filter Predicates
      MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'
    MERGE JOIN
      TABLE ACCESS              CITY               FULL                            11
      BUFFER                                       SORT                        100605
          TABLE ACCESS          MUNICIPALITY       FULL                            20So the cost is in the BUFFER (whatever that is), it takes +2000 seconds to run this, it is not using the spatial index.
And we are not getting all rows, but only the ones interacting with a municipality, e.g. 2436 rows.
But I want all rows, including the ones not interacting with any Municipality.
When we want only those cities that actually are in a municipality, I use a different query and it will use the index.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1, MUNICIPALITY T2
WHERE SDO_RELATE(T1.GEOM, T2.GEOM, 'MASK=ANYINTERACT') = 'TRUE'I get (only) 2436 rows (as expected) in 5 seconds (it is fast) and the explain plan shows it is using the spatial index.
But in this case, I am not getting any cities not inside any municipality (of course)
SELECT STATEMENT
   NESTED LOOPS
      TABLE ACCESS                   MUNICIPALITY       FULL                22
      TABLE ACCESS                   CITY               BY INDEX ROWID      22
         DOMAIN INDEX                CITY_SDX                                0
            Access Predicates
               MDSYS.SDO_RTREE_RELATE(T1.GEOM, T2.GEOM, 'mask=ANYINTERACT querytype=window ') = 'TRUE'I always thought a LEFT OUTER JOIN would return all rows from the Table, whatever happens in the next,
but it seems the query has been rewritten so that it is now using a Filter Predicate in the end, which filters those geometries having no interaction.
As an example I also do thing alphanumerically, I do get 4942 rows, including the ones which have no Municipality name.
In this case the names must match, so its only for testing if the LEFT OUTER JOIN returns stuff correctly, which it does in this case.
SELECT T1.NAME as City, T2.NAME as Municipality
FROM CITY T1
LEFT OUTER JOIN MUNICIPALITY T2 ON T1.NAME = T2.NAMEIs this an Oracle Spatial bug, e.g. not return 4942 rows, but only 2436 rows on the first query?
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)

Patrick,
Even so, your geoms in the relate were the wrong way around.
Also, I don't recall you saying (or showing) that you wanted the municipality geometry returned. Still,
no matter, easy to do.
Here are some additional suggestions. I don't have your data so I have had to use some of my own.
set serveroutput on timing on autotrace on
SELECT T1.SPECIES as City,
       (SELECT T2.ADMIN_NAME FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as Municipality,
       (SELECT T2.GEOM       FROM AUSTRALIAN_STATES T2 WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE') as geom
FROM GUTDATA T1;
762 rows selected
Elapsed: 00:00:21.656
Plan hash value: 2160035213
| Id | Operation                   | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT            |                            |   762 | 49530 |     5   (0)| 00:00:01 |
|   1 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
|* 2 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   3 | TABLE ACCESS BY INDEX ROWID| AUSTRALIAN_STATES          |     1 |   115 |     0   (0)| 00:00:01 |
|* 4 |   DOMAIN INDEX              | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   5 | TABLE ACCESS FULL          | GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
           24576 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksThe above can look messy as you add more (SELECT ...) attributes, but is is fast (though can't use in Materialized Views).
/* The set of all cities not in municipalities */
SELECT T1.SPECIES                 as City,
       cast(null as varchar2(42)) as municipality,
       cast(null as sdo_geometry) as geom
FROM GUTDATA T1
WHERE NOT EXISTS (SELECT 1
                     FROM AUSTRALIAN_STATES T2
                    WHERE SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
UNION ALL
/* The set of all cities in municipalities */
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality,
       T2.GEOM       as geom
FROM GUTDATA T1
       INNER JOIN
       AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:59.953
Plan hash value: 2854682795
| Id | Operation           | Name                       | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |                            |    99 | 13450 |    38 (87)| 00:00:01 |
|   1 | UNION-ALL          |                            |       |       |            |          |
|* 2 |   FILTER            |                            |       |       |            |          |
|   3 |    TABLE ACCESS FULL| GUTDATA                    |   762 | 49530 |     5   (0)| 00:00:01 |
|* 4 |    DOMAIN INDEX     | AUSTRALIAN_STATES_GEOM_SPX |       |       |     0   (0)| 00:00:01 |
|   5 |   NESTED LOOPS      |                            |    61 | 10980 |    33   (0)| 00:00:01 |
|   6 |    TABLE ACCESS FULL| AUSTRALIAN_STATES          |     8 |   920 |     3   (0)| 00:00:01 |
|* 7 |    TABLE ACCESS FULL| GUTDATA                    |     8 |   520 |     4   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   2 - filter( NOT EXISTS (SELECT 0 FROM "AUSTRALIAN_STATES" "T2" WHERE "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE'))
   4 - access("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"(:B1,10000,0.5,'UNIT=M'))='TRUE')
   7 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
          131072 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksMuch slower but Materialized View friendly.
This one is a bit more "natural" but still slower than the first.
set serveroutput on timing on autotrace on
/* The set of all cities in municipalities */
WITH municipal_cities As (
SELECT T1.ID         as City,
         T2.ADMIN_NAME as Municipality,
         T2.GEOM       as geom
    FROM GUTDATA T1
         INNER JOIN
         AUSTRALIAN_STATES T2 ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
SELECT T1.ID           as City,
       T2.Municipality as Municipality,
       T2.GEOM         as geom
FROM GUTDATA          T1
       LEFT OUTER JOIN
       municipal_cities T2
       ON (T2.CITY = T1.ID);
762 rows selected
Elapsed: 00:00:50.228
Plan hash value: 745978991
| Id | Operation             | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT      |                   |   762 | 44196 |    36   (3)| 00:00:01 |
|* 1 | HASH JOIN RIGHT OUTER|                   |   762 | 44196 |    36   (3)| 00:00:01 |
|   2 |   VIEW                |                   |    61 | 3294 |    33   (0)| 00:00:01 |
|   3 |    NESTED LOOPS       |                   |    61 | 10980 |    33   (0)| 00:00:01 |
|   4 |     TABLE ACCESS FULL | AUSTRALIAN_STATES |     8 |   920 |     3   (0)| 00:00:01 |
|* 5 |     TABLE ACCESS FULL | GUTDATA           |     8 |   520 |     4   (0)| 00:00:01 |
|   6 |   INDEX FAST FULL SCAN| GUTDATA_ID_PK     |   762 | 3048 |     2   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   1 - access("T2"."CITY"(+)="T1"."ID")
   5 - filter("MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
           49152 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksFinally, the Pièce de résistance: trick the LEFT OUTER JOIN operator...
set serveroutput on timing on autotrace on
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality,
       T2.GEOM       as geom
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (t2.admin_name = to_char(t1.ID) OR
           SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');
762 rows selected
Elapsed: 00:00:50.273
Plan hash value: 158854308
| Id | Operation           | Name              | Rows | Bytes | Cost (%CPU)| Time     |
|   0 | SELECT STATEMENT    |                   |   762 | 92964 | 2294   (1)| 00:00:28 |
|   1 | NESTED LOOPS OUTER |                   |   762 | 92964 | 2294   (1)| 00:00:28 |
|   2 |   TABLE ACCESS FULL | GUTDATA           |   762 | 49530 |     5   (0)| 00:00:01 |
|   3 |   VIEW              |                   |     1 |    57 |     3   (0)| 00:00:01 |
|* 4 |    TABLE ACCESS FULL| AUSTRALIAN_STATES |     1 |   115 |     3   (0)| 00:00:01 |
Predicate Information (identified by operation id):
   4 - filter("T2"."ADMIN_NAME"=TO_CHAR("T1"."ID") OR
              "MDSYS"."SDO_ANYINTERACT"("T2"."GEOM","SDO_GEOM"."SDO_BUFFER"("T1"."GEOM",10000,0.5,'UNIT=M'))='TRUE')
   Statistics
               7 user calls
               0 physical read total bytes
               0 physical write total bytes
               0 spare statistic 3
               0 commit cleanout failures: cannot pin
               0 TBS Extension: bytes extended
               0 total number of times SMON posted
               0 SMON posted for undo segment recovery
               0 SMON posted for dropping temp segment
               0 segment prealloc tasksTry these combinations to see what works for you.
Interestingly, for me, the following returns absolutely nothing.
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE')
MINUS
SELECT T1.SPECIES    as City,
       T2.ADMIN_NAME as Municipality
FROM GUTDATA           T1
       LEFT OUTER JOIN
       AUSTRALIAN_STATES T2
       ON (t2.admin_name = to_char(t1.ID) OR
           SDO_ANYINTERACT(T2.GEOM, SDO_GEOM.SDO_BUFFER(T1.GEOM,10000,0.5,'UNIT=M')) = 'TRUE');(I leave it to you to see if you can see why as the LEFT OUTER JOIN seems to be working correctly for me but I am not going to dedicate time to detailed checking of results.)
Note all tests performed on Oracle 11g R2 (11.2.0.1.0)
If you get the answer you want: mark the post as answered to assign points.
regards
Simon

ORA-00932 Error using 11g and the SDO_RELATE function. Works fine in 10g

Hello,
If I run this query in Oracle 11g:
SELECT M.FID, MAX(M.VERSION) AS VERSION
FROM SW_PB.A_ROADNODEINFORMATION M, SW_PB.ROADNODE N
WHERE M.REFERENCETOROADNODE = N.FID
AND M.NODEVERSION = N.VERSION
AND M.CATALOGUEID <= 477
AND MDSYS.SDO_RELATE( N.GEOM, MDSYS.SDO_GEOMETRY(2003,81989,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(120000,0,160000,40000)),'MASK=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE'
GROUP BY M.FID;
I get an error regarding the N.GEOM field. The error is as follows:
ORA-00932: inconsistent datatypes: expected - got MDSYS.SDO_ELEM_INFO_ARRAY
The same query runs fine on a 10g database with the same data. I've even truncated the N table and still get the error. I've rebuilt the index but it makes no difference and the metadata is exactly the same for this table as it is for other tables that are involved in a similar query.
It looks like a bug to me but just wondered if anyone else had come across this?
Thanks,
Peter.

Thanks for the reply. I'm really sorry but I haven't created trace files like this for a very long time and have forgotten the best way to read them. This is the start of the trace file, any help with reformatting it would be greatly appreciated.
Thanks,
Peter.
*** 2009-04-23 17:09:22.902
----- Error Stack Dump -----
*** 2009-04-23 17:09:22.917
ORA-00932: inconsistent datatypes: expected - got MDSYS.SDO_ELEM_INFO_ARRAY
----- Current SQL Statement for this session (sql_id=br02jqdwy2utk) -----
SELECT M.FID, MAX(M.VERSION) AS VERSION
FROM SW_PB.A_ROADNODEINFORMATION M, SW_PB.ROADNODE N
WHERE M.REFERENCETOROADNODE = N.FID
AND M.NODEVERSION = N.VERSION
AND M.CATALOGUEID <= 477
AND MDSYS.SDO_RELATE( N.GEOM, MDSYS.SDO_GEOMETRY(2003,81989,NULL,MDSYS.SDO_ELEM_INFO_ARRAY(1,1003,3),MDSYS.SDO_ORDINATE_ARRAY(120000,0,160000,40000)),'MASK=ANYINTERACT QUERYTYPE=WINDOW') = 'TRUE'
GROUP BY M.FID
----- Call Stack Trace -----
calling call entry argument values in hex
location type point (? means dubious value)
skdstdst()+114      CALLrel kgdsdst()+0 FB783A0 2
ksedst1()+91        CALLrel skdstdst()+0
ksedst()+50         CALLrel ksedst1()+0 0 1
dbkedDefDump()+298 CALLrel ksedst()+0 0
5
ksedmp()+40         CALLrel dbkedDefDump()+0 3 0
_dbkdaKsdActDriver( CALLreg 00000000             3
)+841
_dbgdaExecuteAction CALLreg 00000000             7B50420 FB79A4C
()+63
dbgdaRunAction()+3 CALLrel dbgdaExecuteAction 7B50420 4D4C148 20C0002
02 ()+0 FB79A4C
dbgdRunActions()+4 CALLrel dbgdaRunAction()+0 7B50420 A789E54
4
dbgdProcessEventAc CALLrel dbgdRunActions()+0 7B50420 A789E74
tions()+446
__VInfreq__dbgdChkE CALLrel _dbgdProcessEventAc 7B50420 120A3370 A789F64
ventKgErr()+237 tions()+0
dbkdChkEventRdbmsE CALLrel dbgdChkEventKgErr( 7B50420 A7C06F4 3A4
rr()+33 )+0
__PGOSF99__ksfpec() CALLrel _dbkdChkEventRdbmsE 3A4
+110 rr()+0
_dbgePostErrorKGE() CALLreg 00000000             120A3370 3A4
+1601
dbkePostKGEkgsf() CALLrel _dbgePostErrorKGE() 120A3370 A772020 3A4
+49 +0
_kgeade()+268        CALLreg 00000000             120A3370 A772020 3A4
kgesev()+54         CALLrel kgeade()+0
kgesec2()+18        CALLrel kgesev()+0 120A3370 A772020 3A4 2
FB7A200
qctErr932()+217     CALLrel kgesec2()+0 120A3370 A772020 3A4 1 1
FB7A468 1 19 FB7A218
qctErrConvertDataT CALLrel qctErr932()+0 995FBCC0 120A3370 F6 FB7A468
ype()+82 7B C2E85B4 995FBCC0 120A3370
FB7A468 0 0 FB7A468 0 204
qecgby()+240        CALLrel qctErrConvertDataT 995FBCC0 120A3370 F6 0 0 7B
ype()+0 C2E85B4
qecpqbcheck()+75    CALLrel qecgby()+0
qecdrv()+161        CALLrel qecpqbcheck()+0 C2ECD7C 0 0 0
qecdrv()+74         CALLrel qecdrv()+0
kkqcttcalo()+383    CALLrel qecdrv()+0 C2EFBAC
kkqctdrvGBP()+1841 CALLrel kkqcttcalo()+0 C2EFBAC 0 C2EFBAC 166A5D4 0 2
__VInfreq__kkqgbpTr CALLrel _kkqctdrvGBP()+0     A730DD8
avChkTran()+193
_qksqbApplyToQbcLoc CALLreg 00000000             A730DD8 FB7A9BC
()+536
qksqbApplyToQbc()+ CALLrel qksqbApplyToQbcLoc
67 ()+0
kkqctdrvTD()+1000   CALLrel qksqbApplyToQbc()+ A730DD8 2EF2DA0 FB7A9BC 0
0
kkqgbpdrv()+88      CALLrel kkqctdrvTD()+0 A754820 995FBDF4 6
kkqdrv()+1520       CALLrel kkqgbpdrv()+0 A754820 995FBDF4
kkqctdrvIT()+698    CALLrel kkqdrv()+0 A754820 0
apadrv()+1205       CALLrel kkqctdrvIT()+0 A754820 995FBDF4
opitca()+1841       CALLrel apadrv()+0 995FBDF4
__PGOSF435__kksFull CALLrel _opitca()+0          A7CC9E4 995FBDF4
TypeCheck()+15
_rpiswu2()+560       CALLreg 00000000             FB7B718
kksLoadChild()+860 CALLrel rpiswu2()+0 AF495220 5 A77DCBB4 16
8 94591E54 5 A77DCBE0 0 FB7B670
615F44 0 FB7B718 0
kxsGetRuntimeLock( CALLrel kksLoadChild()+0 120A3370 AE9130D8 FB7C090
)+1421
kksfbc()+8954       CALLrel kxsGetRuntimeLock( 120A3370 A7CC9E4 FB7C090 3 1
)+0
kkspsc0()+1882      CALLrel kksfbc()+0 A7CC9E4 3 108 FB7D2D8 1BB 0 0
0
kksParseCursor()+1 CALLrel kkspsc0()+0
43
opiosq0()+2028      CALLrel kksParseCursor()+0 FB7C610
kpooprx()+273       CALLrel opiosq0()+0 3 E FB7C734 A4
kpoal8()+729        CALLrel kpooprx()+0 FB7F214 FB7D2D8 1BA 1 0 A4
_opiodr()+1224       CALLreg 00000000             5E 1C FB7F210
_ttcpip()+2733       CALLreg 00000000             5E 1C FB7F210 0
_opitsk()+1278       CALL??? 00000000
opiino()+1067       CALLrel opitsk()+0 0 0
_opiodr()+1224       CALLreg 00000000             3C 4 FB7FC28
opidrv()+807        CALLrel opiodr()+0 3C 4 FB7FC28 0
sou2o()+45          CALLrel opidrv()+0 3C 4 FB7FC28
opimaireal()+130 CALLrel _sou2o()+0           FB7FC1C 3C 4 FB7FC28
opimai()+92         CALLrel opimai_real()+0 2 FB7FC54
OracleThreadStart@ CALLrel opimai()+0
4()+764
77E6482C CALLreg 00000000
00000000 CALL??? 00000000

Problem with SDO_relate when using polygons with holes.

I'm having a problem with sdo_relate. I'm trying to extract all elements from a point table (bdtq_batim_p) that are inside a specific polygon from another table (SDA_MUNIC_SS). The spatial index for both table have been rebuilt and the data from both table is valid.
When I do a count on the query, I know the answer should be 1422 elements (Counted in ArcGIS). However, sdo_relate gives a smaller number of elements in the result set.
The query :
SELECT count(distinct t.identifiant) FROM bdtq_batim_p t, SDA_MUNIC_SS s WHERE s.mus_co_geo = '48015' and sdo_relate( t.SHAPE,s.SHAPE,'mask=anyinteract querytype=window') = 'TRUE'
returns 282 elements. The query with mask=inside, SDO_Anyinteract() and SDO_inside() all give the same result.
I did a test with the following query and the result is 1422 (which is the good result).
SELECT count(distinct t.identifiant) FROM bdtq_batim_p t, SDA_MUNIC_SS s WHERE s.mus_co_geo = '48015' and SDO_WITHIN_DISTANCE( t.SHAPE,s.SHAPE,'distance=0') = 'TRUE';
It's important to note that the polygone (from SDA_MUNIC_SS) that is used for this query have holes in it. I have the same problem with all the polygons from the SDA_MUNIC_SS table that have holes in it. For the polygon without holes, the results are the same for the 2 queries.
My question are :
Why are the result from the two queries different? A query with a buffer of 0 should always return the same result as a query with Anyinteract.
Is there a known problem with SDO_RELATE when using a polygon with holes in it?
Do you have any idea how to solve my problem.

Since i don't have much control on the version of Oracle and Patches that we use in the system, we used a workaround that detects the polygons with holes and uses the SDO_WITHIN_DISTANCE( t.SHAPE,s.SHAPE,'distance=0') = 'TRUE' operator in those case. We saw a slight decline in performance but it now returns the right results. When the system will be patched, we'll come back to the original version and see if the problem is solved.

SDO_RELATE rectanlge works but circle doesn't?

Hello
I have two queries. the first uses a rectangle to find a polygon ID.
SELECT A.fid FROM f10 A
WHERE sdo_relate(A.points, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(592368.93,46518840.02,596611.9,4655140.11)),
'mask=anyinteract querytype=window') = 'TRUE';
FID
2
The other queries the same polygon but using a circle.
SELECT A.fid FROM f10 A
WHERE sdo_relate(A.points, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,4),
mdsys.sdo_ordinate_array(592368.93,46518840.02,596611.9,4655140.11,592727.22,4656139.56)),
'mask=anyinteract querytype=window') = 'TRUE';
no rows selected
Two of the circle coordinates are the same as the rectangle coordinates, and the third circle coord is also inside the polygon I am querying. Can anyone tell me what is wrong with my circle query?
Any Help is Greatly Appreciated.
Thank You
Shannon
null

Nevermind - I got it.
I tried to delete the thread but was unable.
Sorry
Shannon

Select data with SDO_RELATE in lat long coordinate system(8307) in 10gR2

Hi all,
I have problem with selecting data from table.
Data are in lat lon coordinate system 8307.
These requests don't return any data:
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_FILTER(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,1),sdo_ordinate_array(-180,-90, 180,-90, 180,90, -180,90, -180,-90)) ) = 'TRUE';
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_RELATE(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,1),sdo_ordinate_array(-180,-90, 180,-90, 180,90, -180,90, -180,-90)), 'MASK=ANYINTERACT' ) = 'TRUE'
Optimized polygon does return all data correctly:
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_FILTER(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,3),sdo_ordinate_array (-180,-90,180,90)) ) = 'TRUE'
Smaller polygon select data correctly too.
SELECT ISSUE_ID FROM MAP_ISSUES WHERE SDO_FILTER(GEOMETRY, sdo_geometry (2003, 8307, null, sdo_elem_info_array (1,1003,1),sdo_ordinate_array (52,-7, 54,-7 , 54,-5 , 52,-5, 52,-7)) ) = 'TRUE'
I have tried changed polygon to be clockwise, counter clockwise, make the area a bit smaller( 160 instead of 180, 89 instead of 90) nothing has helped.
My explanation than was, that Earth is sphere and each defined polygon defines TWO polygons in the sphere and there is convention that the smaller is chosen to select data. It would make sense along the previous results, but than I found one post which says that this is bug http://www.frontoracle.com/oracle-database/703/180703-size-of-are-of-interest-smaller-equals.html
I have found in other thread that max only 1/2 of Earth could be selected Different results using SDO_RELATE with polygon and rectangle type but it seems not true, because optimized bounding box works fine!
What is right? Is there anything in official documentation?
Is it bug.
Max 1/2 of Earth could be selected in one request.
Each polygon defines two areas in the Earth and the smaller one is used to do spatial SDO_RELATE operation?
Thanks!
Regards,
Zdenek

Zdenek,
A bug, or limititation, whichever you choose. IMHO if you ask for something, and don't get what you expect, it is a bug that could be fixed.
But for 10g anywho, the following applies, which is why I choose 120 degree breaks for my code as it is less than 180...
The following size limits apply with geodetic data:
■ No polygon element can have an area larger than one-half the surface of the Earth.
■ In a line, the distance between two adjacent coordinates cannot be greater than or
equal to one-half the perimeter (a great circle) of the Earth.
If you need to work with larger elements, first break these elements into multiple
smaller elements and work with them. For example, you cannot create a geometry
representing the entire ocean surface of the Earth; however, you can create multiple
geometries, each representing part of the overall ocean surface. To work with a line
string that is greater than or equal to one-half the perimeter of the Earth, you can add
one or more intermediate points on the line so that all adjacent coordinates are less
than one-half the perimeter of the Earth.
Bryan

SDO_Relate and SDO_filter with SDO_Join

Hi all,
Could someone please help me in finding the difference with the below query
I am comparing SDO_Relate and SDO_filter with SDO_join.
Query using SDO_Relate and SDO_filter
SELECT count(spa1.id)
FROM temp_tab tmp_tab,
spatial_tab spa1,
spatial_tab spa2
WHERE tmp_tab.id = spa1.id
AND sdo_filter (spa2.geo_link, spa1.geo_link) = 'TRUE'
AND spa1.rowid != spa2.rowid
AND sdo_geom.relate (spa1.geo_link, 'ANYINTERACT', spa2.link, .0000005) = 'TRUE'
With this I get a output of 600 rows.
Query using SDO_join
SELECT count(spa1.id)
FROM spatial_tab a, spatial_tab b, temp_tab d,
TABLE(SDO_JOIN('spatial_tab', 'geo_link', 'spatial_tab', 'geo_link',
'mask=ANYINTERACT')) c
WHERE (c.rowid1 = a.rowid AND c.rowid2 = b.rowid)
and (d.id = a.id);
With this I get a output of 750 rows.
I assume that both the query should return 600 rows.
rgds and thanks
saaz

Can you please try:
SELECT count(spa1.id)
FROM spatial_tab a, spatial_tab b, temp_tab d,
TABLE(SDO_JOIN('spatial_tab', 'geo_link', 'spatial_tab', 'geo_link',
'mask=ANYINTERACT')) c
WHERE (c.rowid1 = a.rowid AND c.rowid2 = b.rowid)
and (d.id = a.id) and c.rowid1 != c.rowid2;

Geodetic spatial queries - sdo_relate

Hello,
The following script populates a spatial table with points on a query boundary and then queries that table using the query boundary. When using a srid of 8307 not all of the points are returned using sdo_relate. If the srid is NULL then all points 'on' the query boundary are returned.
In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
Thanks in advance,
Rick
========= Script follows ============
geomdetic relate test case
This script demonstrates cases where sdo_relate, in a geodetic coordate system where
"A two point line on a given meridian, doesn't necessarily follow that meridian,
so any feature touching that meridian between those two points is not necessarily
touching that line""
The script generates an input query boundary using max and min values. It inserts
point features on the query boundary at input interval into a test table. '
A spatial query is executed against the test table using the query boundary.
DECLARE
TYPE ord_type IS TABLE OF NUMBER
INDEX BY BINARY_INTEGER;
x_tab ord_type;
y_tab ord_type;
maxlon NUMBER DEFAULT 65;
minlon NUMBER DEFAULT 64;
maxlat NUMBER DEFAULT 45 ;
minlat NUMBER DEFAULT 44;
INCREMENT NUMBER DEFAULT 0.001;
offset number default 0;
srid number default 8307;
curval NUMBER;
objectnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (objectnotexists, -942);
indexnotexists EXCEPTION;
PRAGMA EXCEPTION_INIT (indexnotexists, -1418);
PROCEDURE populate_array (
p_minval IN NUMBER,
p_maxval IN NUMBER,
p_increment IN NUMBER,
p_array IN OUT ord_type
IS
i BINARY_INTEGER DEFAULT 0;
BEGIN
curval := p_minval;
LOOP
p_array (i) := curval;
curval := curval + INCREMENT;
i := i + 1;
EXIT WHEN curval > p_maxval;
END LOOP;
END populate_array;
PROCEDURE insert_points_on_tangent (
p_tangent IN NUMBER,
p_ords IN ord_type,
orientation IN VARCHAR
IS
v_geom MDSYS.SDO_GEOMETRY;
i BINARY_INTEGER;
BEGIN
i := p_ords.FIRST; -- get subscript of first element
WHILE i IS NOT NULL
LOOP
IF orientation = 'Y'
THEN
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_tangent,
p_ords (i)
ELSE
v_geom :=
MDSYS.SDO_GEOMETRY (2001,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1, 1),
MDSYS.sdo_ordinate_array (p_ords (i),
p_tangent
END IF;
EXECUTE IMMEDIATE 'insert into sdo_relate_geom_test (geom, geom_type) values (:boundary, :geom_tag)'
USING v_geom, orientation || ' ' || i;
i := p_ords.NEXT (i); -- get subscript of next element
END LOOP;
END insert_points_on_tangent;
-- Create a table to hold the geometries.
PROCEDURE TEST
IS
v_geom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
srid,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_viewportgeom MDSYS.SDO_GEOMETRY
DEFAULT MDSYS.SDO_GEOMETRY (2003,
0,
NULL,
MDSYS.sdo_elem_info_array (1, 1003, 1),
MDSYS.sdo_ordinate_array (minlon,
minlat,
maxlon,
minlat,
maxlon,
maxlat,
minlon,
maxlat,
minlon,
minlat
v_expected NUMBER;
v_relate_results NUMBER;
v_filter_results NUMBER;
v_relate_results_arc NUMBER;
v_dimino MDSYS.SDO_DIM_ARRAY;
v_count_sql VARCHAR2 (1000)
DEFAULT 'select count(*) from sdo_relate_geom_test';
v_filter_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_filter '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
v_relate_sql VARCHAR2 (1000)
DEFAULT 'SELECT count(*) '
|| ' FROM sdo_relate_geom_test '
|| ' WHERE MDSYS.sdo_relate '
|| ' (geom, '
|| ' :ingeom, '
|| ' ''MASK= ANYINTERACT QUERYTYPE=WINDOW'' '
|| ' ) = ''TRUE'' ';
BEGIN
EXECUTE IMMEDIATE v_count_sql
INTO v_expected;
EXECUTE IMMEDIATE v_filter_sql
INTO v_filter_results
USING v_geom;
EXECUTE IMMEDIATE v_relate_sql
INTO v_relate_results
USING v_geom;
DBMS_OUTPUT.put_line ( ' boundary minLat '
|| minlat
|| ' minLon '
|| minlon
|| ' maxLat '
|| maxlat
|| ' maxLon '
|| maxlon
||' increment '
|| INCREMENT
DBMS_OUTPUT.put_line ( 'expected '
|| v_expected
|| ' relate returned '
|| v_relate_results
|| ', '
|| 'filter returned '
|| v_filter_results
|| '. '
DBMS_OUTPUT.put_line('');
END TEST;
BEGIN
BEGIN
EXECUTE IMMEDIATE 'drop table sdo_relate_geom_test';
EXCEPTION
WHEN objectnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create table sdo_relate_geom_test(geom mdsys.sdo_geometry, geom_type VARCHAR2(100))';
-- generate the points we want to test
populate_array (minlon, maxlon, INCREMENT, x_tab);
populate_array (minlat, maxlat, INCREMENT, y_tab);
-- insert the points on the query boundary
insert_points_on_tangent (minlon + offset, y_tab, 'Y');
insert_points_on_tangent (maxlon - offset, y_tab, 'Y');
insert_points_on_tangent (minlat + offset, x_tab, 'X');
insert_points_on_tangent (maxlat - offset, x_tab, 'X');
DELETE user_sdo_geom_metadata
WHERE table_name = 'SDO_RELATE_GEOM_TEST';
INSERT INTO user_sdo_geom_metadata
(table_name, column_name,
diminfo,
srid
VALUES ('SDO_RELATE_GEOM_TEST', 'GEOM',
MDSYS.sdo_dim_array (MDSYS.sdo_dim_element ('x',
-180,
180,
.00000005
MDSYS.sdo_dim_element ('y',
-90,
90,
.00000005
srid
BEGIN
EXECUTE IMMEDIATE 'drop index SDO_RELATE_GEOM_TEST_spa_idx';
EXCEPTION
WHEN indexnotexists
THEN
NULL;
END;
EXECUTE IMMEDIATE 'create index SDO_RELATE_GEOM_TEST_spa_idx on SDO_RELATE_GEOM_TEST(geom) indextype is mdsys.spatial_index';
TEST;
END;
/

In https://metalink.oracle.com/metalink/plsql/f?p=130:15:2437246749596129570
there is the statement...
"In a geodetic system, if there is a line defined from lat: 50, long: 30, lat:50, long: 35 that line does not go along the latitude 50 parallel.
Only the two end points will be at lat: 50, all the other interior points on that line will have a latitude value more than 50.
Due to this reason, the points along the lat: 50 are not part of the query window. "
Does anyone know the reasoning behind this statement? How can I determine what the interior points would be between a line defined as start point lat: 50, long: 30 to end point lat:50, long: 35?
In Oracle Spatial's support for geodetic coordinates, the line segments connecting consecutive vertices of a polygon or line string are geodesics - the shortest paths between the vertices on the earth spheroid. The shortest path between {30, 50} and {35, 50) does not coincide with the 50 latitude parallel, but goes to higher latitude. Only at the equator does the geodesic connecting points of constant latitude coincide with the latitude parallel.

SDO_FILTER / SDO_RELATE - no rows returned

Hi, I'm having some troubles with SDO_FILTER and SDO_RELATE functions.
I inserted some spatial data into a table and I can see that spatial information in mapbuilder, but when I query de same data with SQL command line, there are no rows returned. The spatial data isn't georeferenced.
I used this SQL query:
SELECT g.GEOM.Get_WKT() FROM SHPSDO2 g
WHERE sdo_filter(g.GEOM, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, 180, -90, 90)),
'querytype=window') = 'TRUE';
and also this one:
SELECT g.GEOM.Get_WKT() FROM SHPSDO2 g
WHERE SDO_RELATE(g.GEOM, mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, 180, -90, 90)),
'mask=ANYINTERACT querytype=WINDOW') = 'TRUE';
When I execute this query: SELECT SDO_AGGR_MBR(g.GEOM).Get_WKT() FROM SHPSDO2 g
the following row is returned:
POLYGON ((-179.144806 -14.60521, 179.76416 -14.60521, 179.76416 71.332649, -179.144806 71.332649, -179.144806 -14.60521))
That means the data is inside the GEOMETRY filter that I passed.
Can some one help me please ???
Operator
Thanks in advance

when using an optimized rectangle enter lower left x,y, then upper right x,y (or long/lat).
so change:
mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, 180, -90, 90))
to:
mdsys.sdo_geometry(2003,NULL,NULL,
mdsys.sdo_elem_info_array(1,1003,3),
mdsys.sdo_ordinate_array(-180, -90, 180, 90)),

Problem with sdo_relate returning unexpected results

I am having a problem with an oracle spatial query not returning what I feel is an appropriate result.
I have a bounding box that has 6 points from a table that should be inside it. There are several hundred points total in this table. I perform the following query and oracle returns only 4 points, well 5 but we will get to that later, within the area of the search.
SQL> Select feature_id
From city_points A
where (MDSYS.SDO_RELATE(A.GEOM, mdsys.sdo_geometry(2003, 8307, NULL, mdsys.sdo_elem_info_array(1,1003,1), mdsys.sdo_ordinate_array(-101.8417,-52.8083,-23.8417,-52.8083,-23.8417,-13.8083,-101.8417,-13.8083,101.8417,-52.8083)), 'mask=ANYINTERACT querytype=join') = 'TRUE');
I used a different application to perform the same type of query. The difference is that the application does the spatial query, not oracle. Further the application gets all of the points and performs this query on the client. What the application returns is correct both visually and spatially.
Two of the points not returned in the oracle spatial query are 300km inside the bounding box. This far exceeds the .5 m tolerance used in our decimal degrees data set (SRID 8307).
I have experienced this problem on 9.2.0.1. I then patched that instance to 9.2.0.7 and duplicated the problem. I then exported the data and imported into a 10g release 1 database and again duplicated the problem. I have tried to re-index the data to no avail.
I have also tried different querytypes also yielding less than expected results.
The data looks like this:
243
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-58.45, -34.6, NULL),NULL, NULL)
254
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-56.18333, -34.883334, NULL), NULL, NULL)
377
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-70.666671, -33.449999, NULL), NULL, NULL)
385
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-68.149999, -16.5, NULL), NULL, NULL)
388
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-47.916667, -15.783333, NULL), NULL, NULL)
427
SDO_GEOMETRY(2001, 8307, SDO_POINT_TYPE(-57.640066, -25.270295, NULL), NULL, NULL)
The number is the id field, the rest is the geometry.
The oracle spatial query above only returns id #s 359, 377,243,254,427
There are five returned records. The extra value is outside the bounding area. So it should not have been returned at all. It is all too strange.
I have seen this with different geometry types (points lines and area) as well.
If anyone has suggestions, I would appreciate your comments.
Thanks,
John

John,,
What you are seeing is the behavior you should expect in the geodetic space.
When you have a very long line connecting from longitude -101 to -23, that line
does not follow the same latitude value.
Since these points are in southern hemisphere, the line connecting them
will curve downward (this is the great circle line).
If you really want a line connecting with constant latitude, you should
use the MBR type for the window geometry which densifies the
lines along constant latitude before passing it into relate.
SDO_GEOMETRY(2003, 8307, NULL,
sdo_elem_info_array(1,1003,3),
sdo_ordinate_array(-101.8417,-52.8083, 23.8417,-13.8083))
siva

SDO_relate mask EQUAL giving erroneus results

I'm working in Oracle 9i attempting to test our list of maps to find duplicate maps using the SDO_RELATE with equal mask. We're trying to notice if we have any changes between one version of a map for a given territory from it's older/newer versions.
When i compare what i know to be equal maps with the above described query i get a "TRUE" response as expected. When i compare a given map to the entire table full of maps i sometimes get one extra map that says it is equal as well. When i pull up the supposedly equal map it is not at all equal but shares one common border. Its like Missouri and Illinois being called equal. According to all the documentation this should not be the result. TRUE results should be truly EQUAL. Is there any type of known bug about this in Oracle 9i or a way to make it work correctly? How equal are equal results likely to be?

You should try going up to 9208 as many of these type of bugs are fixed in that
patch set.
siva

Can you explain SDO_RELATE and SDO_GEOM.RELATE differences?

Ok, so I'm doing some spatial queries identifying geometries that interact with each other, and everything's groovy until the customer says, ok, get rid of the ones that just touch, which means that a call to SDO_RELATE with an ANYINTERACT mask no longer does the trick. First we tried setting a multiple mask and those queries ran like 9 hours. I figured that since we're burning that much time, we might as well build a table that stores the interaction as identified by DO_GEOM.RELATE with a DETERMINE mask.
Then I noticed an odd thing happening on the way to the forum. For some geometries I get SDO_RELATE with ANYINTERACT returning TRUE and then SDO_GEOM.RELATE returns DISJOINT with the same tolerance that is coded in the metadata (0.5). When tolerance is bumped up to 27, I get TOUCH back. The funny thing is that there are 3 geometries involved here, the reference geom, one that yields TOUCH, and the one that yields DISJOINT.
Stepping back from this behavior, doing some head-scratching and chin-stroking, I ran accross this statement in the Oracle® Spatial User's Guide and Reference 10g Release 2 (10.2) [here.|http://download.oracle.com/docs/html/B14255_01/sdo_operat.htm#i78531]
Unlike with the SDO_GEOM.RELATE function, DISJOINT and DETERMINE masks are not allowed in the relationship mask with the SDO_RELATE operator. This is because SDO_RELATE uses the spatial index to find candidates that may interact, and the information to satisfy DISJOINT or DETERMINE is not present in the index.
Now, how can a function that cannot determine DISJOINT relationships be reliable in determining ANYINTERACT relationships? Actually in this case, the answer we needed is given by SDO_RELATE, as we were looking for a touch relationship for all 3 geometries, except we got the DISJOINT with the SDO_GEOM.RELATE until we cranked up the tolerance.
These are the geometries involved:
Base geom:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.4002777777778, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
Geom that yields ANYINTERACT and TOUCH:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.77888889, 31.3330555608386, -81.59972222, 31.4252777808399, -81.99972222, 31.7997222208455, -81.99972222, 31.4002777808396, -81.88777778, 31.3330555608386, -81.77888889, 31.3330555608386))
Geom that yields ANYINTERACT and DISJOINT:
SDO_GEOMETRY(2003, 8265, NULL), SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.39166667, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222, 31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
Both should touch the base geom along the -81.99972222 or at least both should be disjoint at a tolerance of 0.5 but one is and the other isn't.
So how do I know when to trust SDO_RELATE? How do I know what tolerance will give me consistency?
Oh, yeah, we have the query down to about 45 mins, by using SDO_GEOM.RELATE with DETERMINE and SDO_FILTER in the where clause. (comparing each geometry to each geometry in a table of about 10K rows)

ConSolTed,
It looks to me like the geometries in question are disjoint by 0.000247 meters.
Check my math:
-81.9997222222222 - -81.99972222 = -0.0000000022222 degrees
111,000 meters/degree @equator * -0.0000000022222 * cos(31.4) = -0.000247
So I would expect sdo_geom.relate to return TOUCH for both geometries, and sdo_anyinteract to return TRUE for both, when the tolerance is around .0005 and up. But I've never been good at this math stuff.
Anyone know why ConSolTed's query below, now with a tolerance of 26 meters, returns Disjoint?
SQL> select version from v$instance;
VERSION
10.2.0.4.0
SQL> SELECT
2 SDO_GEOM.RELATE(
3 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.9497
222222222, 32.0836111111111, -82.2163888888889, 31.7502777777778, -81.9997222222222, 31.400277777777
8, -81.9997222222222, 31.8502777777778, -81.9497222222222, 32.0836111111111))
4 , 'determine',
5 SDO_GEOMETRY(2003, 8265, NULL, SDO_ELEM_INFO_ARRAY( 1, 1003, 1), SDO_ORDINATE_ARRAY( -81.391666
67, 31.6836111108438, -81.34972222, 31.8502777808462, -81.99972222, 31.8500000008462, -81.99972222,
31.7997222208455, -81.59972222, 31.4252777808399, -81.52472222, 31.4377777808401, -81.45805556, 31.5
419444408417, -81.47055556, 31.6252777808429, -81.39166667, 31.6836111108438))
6 , 26) relationship
7 FROM dual;
RELATIONSHIP
DISJOINT

Inconsistent SDO_RELATE results when querying 2.5D data

Oracle 11.1.0.7 with Patch 8343061 on Windows Server 2003 32bit.
I'm getting inconsistent results from SDO_RELATE results when querying 2.5D data. Some geometries I expect to be OVERLAPBDYDISJOINT, are not always being returned by SDO_RELATE when using the OVERLAPBDYDISJOINT mask. It seems that the order of the tables makes a difference to the result.
Here's a table with one 2.5D geometry and a 2D index:
CREATE TABLE TEST1 (
ID                NUMBER PRIMARY KEY,
GEOMETRY     SDO_GEOMETRY);
INSERT INTO TEST1 (id, geometry) VALUES (
1,
SDO_GEOMETRY(3002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561695.935, 834005.726, 25.865,
561696.229, 834005.955, 25.867, 561686.278, 834015.727, 26.088, 561685.179, 834019.771, 26.226, 561680.716, 834022.389, 26.226,
561674.434, 834025.125, 26.171, 561671.963, 834032.137, 25.667, 561670.832, 834037.185, 25.619, 561667.946, 834042.976, 25.84,
561666.717, 834047.218, 26.171, 561664.229, 834051.781, 26.778, 561660.041, 834055.935, 26.64, 561657.514, 834061.742, 26.53,
561658.59, 834067.116, 27.882, 561657.67, 834070.739, 28.821, 561653.028, 834073.777, 29.042, 561653.234, 834078.769, 28.379,
561658.336, 834080.105, 29.511, 561664.582, 834079.468, 31.94, 561669.257, 834075.821, 33.707, 561672.716, 834074.456, 33.707,
561676.875, 834077.262, 33.735, 561675.868, 834081.55, 33.707, 561673.131, 834087.641, 33.679, 561672.208, 834093.502, 33.238,
561668.578, 834100.894, 33.735, 561666.013, 834106.399, 33.679, 561661.408, 834111.23, 33.514, 561654.854, 834117.181, 33.486,
561651.695, 834122.292, 33.569, 561649.112, 834128.847, 33.431, 561645.982, 834134.786, 33.293, 561642.485, 834141.235, 33.072,
561642.138, 834150.085, 33.293, 561646.072, 834159.721, 36.578, 561647.274, 834165.532, 37.02, 561646.359, 834170.867, 37.02,
561645.42, 834175.485, 36.799, 561642.44, 834180.977, 36.826, 561638.677, 834185.419, 36.771, 561636.693, 834194.824, 37.158,
561635.462, 834202.105, 37.241, 561631.998, 834208.745, 37.268, 561628.871, 834213.994, 37.241, 561627.554, 834220.393, 37.82,
561625.79, 834226.697, 39.532, 561620.561, 834236.494, 39.891, 561619.265, 834249.687, 39.697, 561619.883, 834260.02, 41.326,
561620.977, 834264.399, 43.093, 561622.557, 834270.723, 43.452, 561622.172, 834276.978, 43.452, 561621.347, 834285.541, 43.479,
561622.214, 834292.055, 43.645, 561619.718, 834302.583, 43.755, 561616.762, 834316.47, 43.755, 561608.842, 834328.241, 43.7,
561606.346, 834334.93, 43.7, 561605.27, 834341.929, 43.7, 561603.925, 834350.648, 43.728, 561602.462, 834358.405, 43.838,
561599.552, 834366.629, 44.031, 561594.551, 834374.291, 43.396, 561590.644, 834383.986, 43.065, 561588.48, 834392.21, 44.942,
561586.923, 834397.32, 46.737, 561584.608, 834402.898, 49.299, 561581.389, 834410.194, 50.077, 561580.437, 834419.49, 51.907,
561580.438, 834427.63, 53.127, 561582.245, 834433.389, 55.791, 561586.664, 834433.397, 57.503, 561593.88, 834433.608, 57.475,
561596.305,834439.653, 57.42, 561591.804, 834445.862, 57.309, 561589.097, 834447.689, 57.014)));
SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST1;
DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST1' AND column_name = 'GEOMETRY';
INSERT INTO user_sdo_geom_metadata VALUES ('TEST1','GEOMETRY',
     MDSYS.SDO_DIM_ARRAY(
     MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Z',-10000,10000,0.0005)
), 2157);
DROP INDEX TEST1_SPIND;
CREATE INDEX TEST1_SPIND ON TEST1(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');And here's another table with a 2D geometry and a 2D index:
CREATE TABLE TEST2 (
ID                NUMBER PRIMARY KEY,
GEOMETRY     SDO_GEOMETRY);
INSERT INTO TEST2 (id, geometry) VALUES (
1,
SDO_GEOMETRY(2002, 2157, NULL, SDO_ELEM_INFO_ARRAY(1, 2, 1), SDO_ORDINATE_ARRAY(561816.516, 834055.581, 561819.504, 834057.173,
561817.942, 834060.818, 561810.044, 834078.997, 561805.576, 834087.634, 561801.572, 834094.299, 561798.558, 834100.467,
561796.254, 834107.637, 561793.754, 834115.605, 561794.049, 834123.694, 561793.698, 834130.518, 561792.905, 834138.883,
561787.867, 834145.772, 561782.544, 834150.548, 561777.707, 834156.53, 561773.945, 834161.32, 561771.061, 834166.957,
561768.155, 834173.131, 561764.735, 834178.744, 561759.603, 834187.782, 561756.146, 834195.493, 561753.416, 834198.821,
561754.141, 834205.691, 561756.768, 834209.681, 561757.217, 834216.701, 561753.086, 834232.46, 561744.371, 834254.589,
561740.936, 834263.001, 561737.198, 834272.208, 561732.231, 834284.915, 561730.52, 834297.01, 561728.339, 834310.053,
561727.825, 834328.069, 561730.461, 834342.992, 561729.808, 834367.948, 561730.216, 834396.988, 561732.273, 834419.047,
561732.783, 834424.668, 561731.647, 834432.212, 561731.872, 834439.436, 561731.39, 834449.269, 561732.041, 834462.813,
561733.583, 834471.926, 561733.229, 834485.049, 561730.868, 834498.462, 561726.379, 834512.59, 561725.776, 834528.932,
561727.488, 834555.23, 561729.357, 834577.873, 561731.05, 834595.931, 561731.163, 834611.928, 561734.057, 834637.031,
561732.67, 834636.4, 561725.401, 834633.796, 561721.039, 834632.493, 561718.777, 834632.167, 561710.437, 834632.888,
561647.929, 834636.658, 561644.963, 834630.085, 561632.796, 834629.813, 561625.553, 834627.647, 561620.473, 834626.711,
561608.718, 834624.94, 561599.935, 834619.684, 561596.67, 834613.843, 561594.27, 834607.774, 561592.513, 834601.752,
561591.349, 834593.899, 561597.265, 834584.888, 561595.956, 834571.479, 561595.075, 834556.196, 561593.997, 834539.68,
561594.316, 834528.071, 561595.261, 834516.44, 561595.538, 834504.804, 561597.227, 834497.417, 561599.3, 834490.416,
561601.265, 834482.61, 561605.126, 834475.502, 561599.232, 834473.683, 561593.076, 834471.379, 561599.154, 834451.112,
561589.097, 834447.689, 561591.804, 834445.862, 561596.305, 834439.653, 561593.88, 834433.608, 561582.245, 834433.389,
561580.438, 834427.63, 561580.437, 834419.49, 561581.389, 834410.194, 561584.608, 834402.898, 561586.923, 834397.32,
561588.48, 834392.21, 561590.644, 834383.986, 561594.551, 834374.291, 561599.552, 834366.629, 561602.462, 834358.405,
561603.925, 834350.648, 561605.27, 834341.929, 561606.346, 834334.93, 561608.842, 834328.241, 561616.762, 834316.47,
561619.718, 834302.583, 561622.214, 834292.055, 561621.347, 834285.541, 561622.172, 834276.978, 561622.557, 834270.723,
561620.977, 834264.399, 561619.883, 834260.02, 561619.265, 834249.687, 561620.561, 834236.494, 561625.79, 834226.697,
561627.554, 834220.393, 561628.871, 834213.994, 561631.998, 834208.745, 561635.462, 834202.105, 561636.693, 834194.824,
561638.677, 834185.419, 561642.44, 834180.977, 561645.42, 834175.485, 561646.359, 834170.867, 561647.274, 834165.532,
561646.072, 834159.721, 561642.138, 834150.085, 561642.485, 834141.235, 561645.982, 834134.786, 561649.112, 834128.847,
561651.695, 834122.292, 561654.854, 834117.181, 561661.408, 834111.23, 561666.013, 834106.399, 561668.578, 834100.894,
561672.208, 834093.502,561673.131, 834087.641, 561675.868, 834081.55, 561676.875, 834077.262, 561672.716, 834074.456,
561669.257, 834075.821, 561664.582, 834079.468, 561658.336, 834080.105, 561653.234, 834078.769, 561653.028, 834073.777,
561657.67, 834070.739, 561658.59, 834067.116, 561657.514, 834061.742, 561660.041, 834055.935, 561664.229, 834051.781,
561666.717, 834047.218, 561667.946, 834042.976, 561670.832, 834037.185, 561671.963, 834032.137, 561674.434, 834025.125,
561680.716, 834022.389, 561685.179, 834019.771, 561686.278, 834015.727, 561696.229, 834005.955, 561695.935, 834005.726,
561677.805, 833994.91, 561683.163, 833985.817, 561703.01, 833949.434, 561725.891, 833961.856, 561744.35, 833971.197,
561768.396, 833983.86, 561777.842, 833988.883, 561798.333, 833999.743, 561797.243, 834005.725, 561783.574, 834040.515,
561798.127, 834046.391, 561807.001, 834050.509, 561816.516, 834055.581)));
SELECT sdo_geom.validate_geometry_with_context(geometry, 0.0005) FROM TEST2;
DELETE FROM user_sdo_geom_metadata WHERE table_name = 'TEST2' AND column_name = 'GEOMETRY';
INSERT INTO user_sdo_geom_metadata VALUES ('TEST2','GEOMETRY',
     MDSYS.SDO_DIM_ARRAY(
     MDSYS.SDO_DIM_ELEMENT('X',400000,750000,0.0005),
     MDSYS.SDO_DIM_ELEMENT('Y',500000,1000000,0.0005)
), 2157);
DROP INDEX TEST2_SPIND;
CREATE INDEX TEST2_SPIND ON TEST2(GEOMETRY) INDEXTYPE IS MDSYS.SPATIAL_INDEX PARAMETERS ('layer_gtype=line sdo_indx_dims=2');Now if I check how these two geometries relate to each other, the answer is OVERLAPBDYDISJOINT, which makes sense when inspecting the geometries.
SQL> SELECT
2 sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate_1_to_2,
3 sdo_geom.relate(t2.geometry, 'determine', t1.geometry, 0.0005) relate_2_to_1
4 FROM test2 t2, test1 t1
5 WHERE t1.id = t2.id;
RELATE_1_TO_2        RELATE_2_TO_1
OVERLAPBDYDISJOINT   OVERLAPBDYDISJOINT
1 row selected.So, I'd expect this query to return something...
SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate
FROM test2 t2, test1 t1
WHERE sdo_relate(t1.geometry, t2.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
AND t1.id = 1
AND t2.id = 1;Nada. And this...
SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate
FROM test1 t1, test2 t2
WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
AND t1.id = 1
AND t2.id = 1;Nada.
And this...
SQL> SELECT /*+ ORDERED */ t1.id, t2.id, sdo_geom.relate(t1.geometry, 'determine', t2.geometry, 0.0005) relate
2 FROM test2 t2, test1 t1
3 WHERE sdo_relate(t2.geometry, t1.geometry, 'mask=overlapbdydisjoint') = 'TRUE'
4 AND t1.id = 1
5 AND t2.id = 1;
        ID         ID RELATE
         1          1 OVERLAPBDYDISJOINT
1 row selected.This version gives the right answer.
Can anyone explain this?

Hi,-
I think you are running into these bugs 7158518 and 7710726.
Could you please request the patch for the bugs so that they are published on Metalink
if they dont exist there?
Please let us know if these fix your problem.
Best regards
baris

SDO_RELATE and SDO_BUFFER

Hi Folks,
I created a generic stored procedure that gets a table and a polygon coordinates as parameters and returns
the table records that satisfy a relationship.
One example of fhe SQL executed by the procedure is:
select GEOFT_MESORREGIAO.* from GEOFT_MESORREGIAO
where SDO_RELATE(GEOFT_MESORREGIAO.MES_GM_POLIGONO,
SDO_GEOMETRY(2003,2000004,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420)),'mask=ANYINTERACT') ='TRUE'
The GEOFT_MESORREGIAO stores polygon geometries.
Running the example I got 7 rows as result.
In the same procedure, users can pass additional parameters to create a buffer around the polygon defined as the query window.
In this case, the SQL executed is:
select GEOFT_MESORREGIAO.* from GEOFT_MESORREGIAO
where SDO_RELATE(GEOFT_MESORREGIAO.MES_GM_POLIGONO,
SDO_GEOM.SDO_BUFFER(SDO_GEOMETRY(2003,2000004,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420)),10,0.05,'unit=KM'),'mask=ANYINTERACT') ='TRUE'
Running this example I got 6 rows as result.
This is not right to me, because if I'm using a bigger query window created by the buffer function, it was expected to get more rows
as result or, at least, the same number of rows returned by the first example.
This was tested in Oracle 11g R1.
Am I missing anything?
Regards,
Luis

Hi
When validating your inline geometry, it returns a ORA-13348: polygon boundary is not closed.
The first coordinate should be repeated at the end to close a ring in a polygon.
SDO_GEOMETRY(2003,8236,NULL,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(-51.427259,-20.547785,-51.575114,-22.289193,-49.094429,-22.387763,-49.028716,-20.457420*,-51.427259,-20.547785*))
will validate.
Try it and see if your results are as expected.
Luc

Sdo_relate in alternate user with views.

Hello,
I am using Oracle 8.1.7.2 and creating a view as follows.
CREATE OR REPLACE VIEW REPORT_STREETINFO AS
SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
MAX(ST.TONRLE) MAX_TONRLE,
NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
MAX(ST.TONRRI) MAX_TONRRI,
MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET MKT_STREET,
MKT.CITY MKT_CITY,
MKT.ZIP MKT_ZIP,
MKT.PO_BOX MKT_POBOX
FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
WHERE PRIM_NAME IS NOT NULL AND
(ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
DTWA.DISTAREA_ID = DT.ID AND
WA.WASID = DTWA.WASID AND
MKT.SRNO = DT.MARKET_ID AND
MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
querytype=window') = 'TRUE'
GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP, MKT.PO_BOX
ORDER BY PRIM_NAME
I grant the rights to this above view to an alternate user. When
I fire a query like
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 22;
from the owner of the view I have no problems but when I fire
this query from alternate user I get error
ORA-03113 end-of-file on communication channel.
I checked out the documentation which states from physical
failure but this is definately not the case.
Any help on this problem will be appretiated.
Amol.

Hello Ravi,
I am posting a spool file which shows the steps I have followed
and error that I get. I have taken care with the grants from
mdsys for the SDO_RELATE and all the other operators.
DEV>SHO USER
USER ist "GEODIS"
DEV>CREATE OR REPLACE VIEW REPORT_STREETINFO AS
2 SELECT DT.ID, MKT.CODE MKT_CODE, PRIM_NAME,
3 NVL(MIN(DECODE(ST.FROMNRLE, 0, NULL, ST.FROMNRLE)),0)
MIN_FROMNRLE,
4 MAX(ST.TONRLE) MAX_TONRLE,
5 NVL(MIN(DECODE(ST.FROMNRRI, 0, NULL, ST.FROMNRRI)),0)
MIN_FROMNRRI,
6 MAX(ST.TONRRI) MAX_TONRRI,
7 MKT.NAME MKT_NAME, MKT.NAME2 MKT_NAME2, MKT.STREET
MKT_STREET, MKT.CITY MKT_CITY,
8 MKT.ZIP MKT_ZIP,
9 MKT.PO_BOX MKT_POBOX
10 FROM STREETINFO ST, DISTAREA DT, MARKET MKT, DISTAREA_WA
DTWA,WALKERAREA WA
11 WHERE PRIM_NAME IS NOT NULL AND
12 (ST.FROMNRLE != 0 AND ST.TONRLE != 0 OR
13 ST.FROMNRRI != 0 AND ST.TONRRI != 0) AND
14 DTWA.DISTAREA_ID = DT.ID AND
15 WA.WASID = DTWA.WASID AND
16 MKT.SRNO = DT.MARKET_ID AND
17 MDSYS.SDO_RELATE(ST.GEOLOC, WA.GEOLOC, 'mask=
(inside+coveredby+on)
18 querytype=window') = 'TRUE'
19 GROUP BY PRIM_NAME, MKT.CODE, DT.ID,
20 MKT.NAME, MKT.NAME2, MKT.STREET, MKT.CITY, MKT.ZIP,
MKT.PO_BOX
21 ORDER BY PRIM_NAME
22 /
View wurde angelegt.
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
PRIM_NAME
Altenhagener
Weg
Alter
Zollweg
Am
Knill
Am
Kroog
Am
Lehmberg
Babenstieg
Bargteheider
Strasse
Bekassinenau
Blomeweg
Boltenhagener
Strasse
Bublitzer
Strasse
Carlssonweg
Farmsener
Zoll
Finkenfurth
Grvmitzer
Weg
Grundherrenstrasse
Herwardistrasse
Hohenkamp
Hoher
Berg
Im
Wiesengrund
Jacobshagener
Weg
Kohvvedstrasse
Kvsliner
Strasse
Krohnsheide
K|hlungsborner
Strasse
Nienhagener
Strasse
Pfefferstrasse
Rahlstedter
Stieg
Rahlstedter
Weg
Raschweg
R|genwalder
Strasse
Rummelsburger
Strasse
Sandkule
Scharbeutzer
Strasse
Sierksdorfer
Strasse
Stargarder
Strasse
Thiessenweg
Timmendorfer
Stieg
Timmendorfer
Strasse
Treptower
Strasse
Wolliner
Strasse
41 Zeilen ausgewdhlt.
DEV>GRANT SELECT ON REPORT_STREETINFO TO PWEIH;
Benutzerzugriff (Grant) wurde erteilt.
DEV>CREATE SYNONYM PWEIH.REPORT_STREETINFO FOR
GEODIS.REPORT_STREETINFO;
Synonym wurde angelegt.
DEV>CONN PWEIH/PWEIH@DEVELOP
Connect durchgef|hrt.
DEV>DESC REPORT_STREETINFO;
Name Null? Typ
ID NOT NULL NUMBER(10)
MKT_CODE VARCHAR2(10)
PRIM_NAME VARCHAR2(40)
MIN_FROMNRLE VARCHAR2(40)
MAX_TONRLE NUMBER
MIN_FROMNRRI VARCHAR2(40)
MAX_TONRRI NUMBER
MKT_NAME VARCHAR2(40)
MKT_NAME2 VARCHAR2(40)
MKT_STREET VARCHAR2(40)
MKT_CITY VARCHAR2(40)
MKT_ZIP VARCHAR2(9)
MKT_POBOX VARCHAR2(40)
DEV>SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108;
SELECT PRIM_NAME FROM REPORT_STREETINFO WHERE ID = 108
FEHLER in Zeile 1:
ORA-03113: Unerwartetes \bertragungsende in Kommunikation
DEV>SPOOL OFF;
Regards,
Amol.

Sdo_relate()

Similar Messages

Maybe you are looking for