Internal error in R-tree processing: [Recursive fetch error]

Question

Hello,
I seem to be getting an error when using any type of SDO function (SDO_RELATE, SDO_FILTER, SDO_ NN, ... ) on my spatially indexed data. The error I'm getting is this:
ERROR at line 1:
ORA-29903: error in executing ODCIIndexFetch() routine
ORA-13236: internal error in R-tree processing: []
ORA-13236: internal error in R-tree processing: [Recursive fetch error]
The interesting part of this is that I only get this error if I insert more than 31 entries into the table. All the relevant code is posted below, what I do is create the table, then create the metadata from the sqlplus interface. After that I run a java program that does Clear() then Insert() then Create_Indices(). All these run just fine (at least run without telling me about any errors). But as soon as that is all done and I do an SDO query on the data, for example:
SELECT location stop_range_poly_area
FROM stops
WHERE SDO_FILTER
location,
SDO_GEOMETRY
2003, null, null,
SDO_ELEM_INFO_ARRAY(1,1003,1),
SDO_ORDINATE_ARRAY(300,300, 600,300, 600,600, 300,600, 300,300)
) = 'TRUE';
I get the above mentioned error. But if I change my data so that it doesn't have more than 31 entries (doesn't matter which 31 entries, just so long as it doesn't exceed that number) that query (and all of my other SDO test queries on the stops table) seems to work just fine.
Thanks for looking at this,
Brad
---- SQLPLUS Code -----------------------------------------------------------------------------------------------------------
CREATE TABLE stops
stop_id VARCHAR2(4) PRIMARY KEY,
address VARCHAR2(256),
location sdo_geometry
INSERT INTO user_sdo_geom_metadata VALUES
'stops',
'location',
MDSYS.SDO_DIM_ARRAY
MDSYS.SDO_DIM_ELEMENT('X', 0, 600, 0.005),
MDSYS.SDO_DIM_ELEMENT('Y', 0, 800, 0.005)
null
----- Java Code -----------------------------------------------------------------------------------------------------------------
// Clear
// Description:
// This function clears all the data in the stop tables in the database
// given in the connection.
public static void Clear (Connection connection)
Statement statement;
try
statement = connection.createStatement();
statement.executeUpdate("DROP INDEX stops_index");
statement.executeUpdate("DELETE stops");
statement.close();
catch (SQLException e)
System.err.println("SQLExcpetion (Stop.Clear()): " + e.getMessage());
// Create_Indices
// Description:
// Create indices for stops table
public static void Create_Indices (Connection connection)
Statement statement;
String sql_query;
sql_query = "CREATE INDEX stops_index ON stops(location) " +
"INDEXTYPE IS MDSYS.SPATIAL_INDEX";
try
statement = connection.createStatement();
statement.executeUpdate(sql_query);
statement.close();
catch (SQLException e)
System.err.println("SQLExcpetion (Stop.Create_Indices()): " + e.getMessage());
// Insert
// Description:
// This function inserts this object into the stops table in the database
// given in the connection.
public void Insert (Connection connection)
Statement statement;
String sql_query;
sql_query = "INSERT INTO stops VALUES ('" +
stop_id + "', '" +
address + "', " +
"sdo_geometry(2001, null, sdo_point_type(" +
location.x + "," +
location.y + ",null), null, null)" +
try
statement = connection.createStatement();
statement.executeUpdate(sql_query);
statement.close();
catch (SQLException e)
System.err.println("SQLException (Stop.Insert()):" + e.getMessage());
Message was edited by: loos to include the changes proposed by the second poster.

Answer 1

Hi,
Thanks for trying but changing those items for the specific failing queries didn't seem to help. Though you do seem to be right about the internal/external polygon problem, so I changed it all my other queries to see if they would fail (that way things would at least be consistent), but it doesn't seem to make a difference. All my old failing quries still fail and my working ones still work. I also changed the co-ordinates as you specified and still have no changes (unless of course the results changed, but right now I'm just looking for queries that compile and run, the results don't matter yet).
Maybe this will help, I'll give you guys both sets of data, one that works and one that doesn't and maybe you can see a problem in the data that I'm just missing or too ignorant to see. The data is simply comma seperated values that I parse into the required fields in the order (id, description, x, y).
So far, the only reason I've been able to find that the non-working data doesn't work is because there are more than 31 rows. I started taking records out of the stops table in a binary search sort of pattern. If I take out stops 100-115 (resulting 29 records) all the queries work, if I take out stops 100-107 (resulting in 36 records) it doesn't work. If I take out 109-115 (resulting in 35 records) it doesn't work. If I take out 1-11 (resulting in 32 records) it doesn't work. If I take out 1-12 (resulting in 31 records) it does work. Here's a table
Take out Stops ---- records left -- Works?
s1-s11 ------------ 32 ------------ No
s1-s12 ------------ 31 ------------ Yes
s100-s115 --------- 29 ------------ Yes
s100-s107 --------- 36 ------------ No
s109-s115 --------- 35 ------------ No
Thanks again for checking this out,
Brad
------- Working Data ---------------------------------------------------------------------------------------
(Student_id, Department, x, y)
Student_1,Computer Science ,296,131
Student_2,Social Science,130 ,279
Student_3,Mechanical Engineering ,392,180
Student_4,Electrical Engineering ,342,322
Student_5,Computer Science ,165,490
Student_6,Scicology ,393,533
Student_7,Physical Therapy ,590,616
Student_8,Civil Engineering ,165,640
Student_9,English ,360,412
Student_10,Economy ,89,32
Student_11,Computer Science ,26,117
Student_12,Social Science,430 ,291
Student_13,Mechanical Engineering ,382,80
Student_14,Electrical Engineering ,542,222
Student_15,Computer Science ,154,290
Student_16,Scicology ,493,323
Student_17,Physical Therapy ,290,426
Student_18,Civil Engineering ,65,230
Student_19,English ,300,412
Student_20,Economy ,44,292
Student_21,Computer Science ,146,431
Student_22,Social Science,405 ,179
Student_23,Mechanical Engineering ,192,480
Student_24,Electrical Engineering ,412,202
Student_25,Computer Science ,265,49
Student_26,Scicology ,33,273
Student_27,Physical Therapy ,186,216
Student_28,Civil Engineering ,365,600
Student_29,English ,309,42
Student_30,Economy ,415,392
------- Non Working Data ---------------------------------------------------------------------------------
(Stop_id, Address, x, y)
s1, 2341 Portland,377,64
s2, 24th St. / Hoover St.,308,22
s3, 2620 Monmouth Ave.,272,138
s4, 2632 Ellendale Pl.,128,110
s5, 2726 Menlo Ave.,85,231
s6, 2758 Menlo Ave.,84,124
s7, 28th St. / Orchard Ave.,183,236
s8, 28th St. / University Ave.,414,308
s9, 30th St. / University Ave.,391,352
s11, 34th St. / McClintock St.,180,458
s12, 36th Pl. / Watt Way,176,622
s13, Adams Blvd. / Magnolia Ave.,218,87
s14, BG Mills Apts.,23,637
s15, Cardinal Gardens Apts.,156,389
s16, Centennial Apts.,373,126
s17, Chez Ronee Apts.,446,414
s18, City Park Apts.,70,323
s19, Dental School,219,478
s96, Founders Apts.,373,192
s97, Hillview Apts.,412,214
s98, House of Public Life,531,303
s99, JEP,304,523
s100, Kerchoff Apts.,473,272
s101, Leavey Library,370,559
s103, McClintock St. / Childs Way,129,553
s104, Mt. St. Marys College,565,127
s105, Pacific Apts.,398,240
s107, Parking Center,525,652
s109, Parkside,78,651
s110, Severance St. / Adams Blvd.,435,202
s111, Research Annex,492,776
s112, Sierra Apts.,352,230
s113, Sunset Apts.,267,278
s114, Terrace Apts.,156,280
s115, Troy East Apts.,402,397
s116, University Regents Apts.,182,181
s117, Watt Way / 36th Pl.,176,622
s119, Watt Way / Bloom Walk,158,653
s120, Windsor Apts.,257,236
s121, Zemeckis Center,476,474
s137, Gate #2,321,715
s138, 24th St. / Toberman St.,377,64