Af:query inconsistency

Hi,
I am developing using Oracle JDeveloper 11.1.1.6.0 and have a small query regarding an in consistency I have noticed with the af:query maybe someone has noticed before.
So my scenario (simplified to the point where I have isolated that case) is:
* Using HR schema
* 2 page fragments within a BTF.
* The 2 pages use iterators that are based on the same VO, and each on is equipped with af:query based on the same view criteria.
* Each of the page points to the other, so the first page has a next button that goes to the second page, and the second page has a previous button that goes back to the first page.
* I have a simple view criteria that match on the first name
Here is what I am noticing:
* When I start the app, I get an empty selection in the af:query and empty table (as expected)
* I type 'Nancy' and press enter, I get the record that matches criteria (as expected)
* I press next to go to the next page, I get an empty selection criteria and table (not sure what to expect !)
* Now, in the second page type 'Guy' for the selection criteria and press enter, I get the record that matches the criteria (as expected)
* i press previous, and now the first page shows 'Guy' and the record that matches in the table (hmmmmmm).
* I type 'y' in the first page and search get all the records that have 'y' in the first name (as expected)
* Press next, now the second page shows 'y' in the section criteria and the table also shows the record that matches (double hmmmmmm)
From there on, it seems that whatever update I make on the first or the second page selection criteria and result gets reflected on the second page.
My believe is this is not an expected behaviour, I am not sure if I am having the wrong assumption or there is something that I should bring up with Oracle.
You assistance in this matter is much appreciated.
Regards,
Younis Al-Rawi

Hi Timo,
Thanks for your response.
The behaviour that I have seen in the subsequent navigation between the first page and the second page is the expected behaviour, however if you notice in my scenario the first time I navigate from the first page to the second page the data control don't seem to be shared. Unless first navigation behaviour is also expected, as I find it to be really strange behaviour.
Looking forward to your response.
Regards,
Younis

Similar Messages

Error while trying to choose query parameter Inconsistent input paramete

I got error on PRD while trying to choose parameter before executing BEX query:
101 Inconsistent input parameter (parameter: <unknown>, value <unknown>)
100 Program error in class SAPMSYY1 method: UNCAUGHT_EXCEPTION
Notes:
the same functionality works fine in DEV environment.
the other parameters on query in PRD work fine
the parameter with error based on custom hierarchy
P.S. I heart BEx :]

Hello,
This problem has been solved before with notes 1236774, 1151320 & 1264213.
Please check.
Thanks,
Michael

Query resulting inconsistent results

Hi,
I'm running Oracle 10.2.0.4 and have a partitioned table.
When I run the query
select bse_rem_bse, ben_aly_num from dw_cn2.prs_old
where bse_rem_bse = 3
I'm getting records with null data (i.e. bse_rem_bse is 'null') and the correct data (i.e. bse_rem_bse is 3).
bse_rem_bse is a number type data field.
Can anyone help me understanding the inconsistent result
and how to find what's broken in table.
Thanks
Tarun

Post your table structure along with data type and some sample data here. Also, post your DB version by executing the following query -
select * from v$version;Regards.
Satyaki De.

Search Results web part - Custom Query using "Value with a parameter from URL" inconsistent

I have encountered what I think may be a bug, but I am hoping that there is something that I am missing.
Within my search site, I have created a new search results page where I want to customize the "Search Results" web part query. I can add in any number of property and keyword filters (using the "Build Your Query" dialog) without
issue... until I add a filter that uses the QueryString property (the builder dialog calls this "Value with a parameter from URL").
If I use {QueryString.MyParameterX} for filtering, it works beautifully in the query builder dialog. I see the expected results in the search results preview pane, but as soon as I apply the changes things become inconsistent.
If I close/reopen my browser and navigate to my page at http://myaddress/search/Pages/testresults.aspx?MyParameterX=test I see results. If I then refresh the page, I get a "Nothing here matches your search" message. I can then go to
the same address but change one character to an uppercase character and get results. Refreshing that same page again returns "Nothing here matches your search". I can only get search results one time per uniquely cased URL without having
to close/reopen my browser. This behavior was seen on both Firefox and IE.
Finally, I found that if I instead navigate to http://myaddress/search/testresults?MyParameterX=test, it always returns results. This, unfortunately isn't the best solution for me... but it is a solution.
Any insight that anyone can provide is greatly appreciated! I would really like to be able to depend on this working in all logical cases (especially since the search center of other sites is set using the path all the way down to /Pages).
Thanks!

Hi, have you been able to solve this issue? I'm getting the same issue and I cant solve it (required CU is installed).
Fabio

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

Inconsistent results returned from the same query

Hi,
My company has a oracle 8i DB as backend for the website it is currently hosting. I wrote a plain SQL select query to retrive results from a table. Usually the query returns 50 to 100 records. We build an xml based on the results and cache the xml for subsequent user hits.
But atleast once or twice a day we get a problem where it returns almost no records. So the resulting xml will be blank and from there on until we delete the cached xml the user sees the page as blank.
I wonder why this happens, does this happen because of more hits to the oracle database?. Or is it because of the indexes created on the table?. Is oracle not able to handle multiple user requests?. We get mostly like 10 to 20 people clicking at the same time. I don't know what is causing the failure.
Does any of you have this inconsistency problems with Oracle?
Thanks in advance
sony

Please ask questions on Oracle Text (formerly InterMedia text) in the Oracle Text forum, you will get a quicker, more expert answer there.

Inconsistent Query Result in SEM-BCS using Virtual Info Provider

We have just upgraded to BW 7.0 and SEM-BCS 6.0. When we run an existing 3.5 BW query for BCS through the Virtual Info Provider against the basic consolidation cube, we are getting inconsistent results. Sometimes we get the correct result, and other times our results are not rolling up correctly causing an out of balance on our balance sheet query. We did not make any hierarchy changes between the query executions. Has anyone else experienced this? We cannot see the cause of the inconsistency. Everything looks good when running through RSRT DEBUG. Any help on pushing us in the right direction to solve this would be appreciated.
Thanks,
Rob

Hi Rob,
Could you please let me know how you have resolved this issue? Thanks.
Regards,
Ashok

Getting Inconsistent Query Results

I am getting inconsistent results when trying to filter data based on the DATETIME stamp. Any help will be appreciated.
Here is my table information.
TableA:
SR DATE
15     8/30/2007 9:34:41 AM
16     9/4/2007 1:03:38 PM
17     9/4/2007 2:50:48 PM
18     9/4/2007 3:04:03 PM
19     9/5/2007 11:47:58 AM
20     9/5/2007 12:16:23 PM
21     9/6/2007 3:34:38 PM
22     9/6/2007 3:43:27 PM
23     9/6/2007 3:46:27 PM
24     9/7/2007 10:14:26 AM
25     9/7/2007 10:16:11 AM
26     9/18/2007 1:03:47 PM
27     9/19/2007 9:31:14 AM
28     9/19/2007 9:44:36 AM
29     9/19/2007 4:18:05 PM
30     9/21/2007 10:44:52 AM
Now if I execute this query,
SELECT * FROM TableA WHERE DATE >= '9/3/2007 9:34:41 AM'
Result (Missing all 2 digit dates:
16     9/4/2007 1:03:38 PM
17     9/4/2007 2:50:48 PM
18     9/4/2007 3:04:03 PM
19     9/5/2007 11:47:58 AM
20     9/5/2007 12:16:23 PM
21     9/6/2007 3:34:38 PM
22     9/6/2007 3:43:27 PM
23     9/6/2007 3:46:27 PM
24     9/7/2007 10:14:26 AM
25     9/7/2007 10:16:11 AM
If I change the day in query to 2 digit then I am getting correct results.
SELECT * FROM TableA WHERE DATE >= '9/03/2007 9:34:41 AM'
But If I run this query:
SELECT * FROM TableA WHERE DATE >= '9/05/2007 9:34:41 AM'
Results (Getting all the dates even less than '9/5/2007':
16     9/4/2007 1:03:38 PM
17     9/4/2007 2:50:48 PM
18     9/4/2007 3:04:03 PM
19     9/5/2007 11:47:58 AM
20     9/5/2007 12:16:23 PM
21     9/6/2007 3:34:38 PM
22     9/6/2007 3:43:27 PM
23     9/6/2007 3:46:27 PM
24     9/7/2007 10:14:26 AM
25     9/7/2007 10:16:11 AM
26     9/18/2007 1:03:47 PM
27     9/19/2007 9:31:14 AM
28     9/19/2007 9:44:36 AM
29     9/19/2007 4:18:05 PM
30     9/21/2007 10:44:52 AM
The results are so inconsistent with different combination, I could not figure out the main reason behind this.
The datatype for this field in database is "VARCHAR2(250)" and because of some restrictions, I could not change datatype of this field in the table.

SQL> DESC t;
Name                                      Null?    Type
COL                                                VARCHAR2(50)
SQL> SELECT col FROM t ORDER BY col;
COL
8/30/2007 9:34:41 AM
9/03/2007 9:34:41 AM
9/05/2007 9:34:41 AM
9/18/2007 1:03:47 PM
9/19/2007 4:18:05 PM
9/19/2007 9:31:14 AM
9/19/2007 9:44:36 AM
9/21/2007 10:44:52 AM
9/3/2007 9:34:41 AM
9/4/2007 1:03:38 PM
9/4/2007 2:50:48 PM
9/4/2007 3:04:03 PM
9/5/2007 11:47:58 AM
9/5/2007 12:16:23 PM
9/6/2007 3:34:38 PM
9/6/2007 3:43:27 PM
9/6/2007 3:46:27 PM
9/7/2007 10:14:26 AM
9/7/2007 10:16:11 AMThe ones in bold are your predicate "dates". Do you see why it doesn't work as you expect?
John

Problems with java constructor: "inconsistent data types" in SQL query

Hi,
I tried to define a type "point3d" with some member functions, implemented in java, in my database. Therefor I implemented a class Point3dj.java as you can see it below and loaded it with "loadjava -user ... -resolve -verbose Point3dj.java" into the database.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
package spatial.objects;
import java.sql.*;
public class Point3dj implements java.sql.SQLData {
public double x;
public double y;
public double z;
public void readSQL(SQLInput in, String type)
throws SQLException {
x = in.readDouble();
y = in.readDouble();
z = in.readDouble();
public void writeSQL(SQLOutput out)
throws SQLException {
out.writeDouble(x);
out.writeDouble(y);
out.writeDouble(z);
public String getSQLTypeName() throws SQLException {
return "Point3dj";
public Point3dj(double x, double y, double z)
this.x = x;
this.y = y;
this.z = z;
public static Point3dj create(double x, double y, double z)
return new Point3dj(x,y,z);
public double getNumber()
return Math.sqrt(this.x*this.x + this.y*this.y + this.z*this.z);
public static double getStaticNumber(double px, double py, double pz)
return Math.sqrt(px*px+py*py+pz*pz);
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Additionally, I created the corresponding type in SQL by
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
CREATE OR REPLACE TYPE point3dj AS OBJECT EXTERNAL NAME
'spatial.objects.Point3dj' LANGUAGE JAVA USING SQLDATA (
x FLOAT EXTERNAL NAME 'x',
y FLOAT EXTERNAL NAME 'y',
z FLOAT EXTERNAL NAME 'z',
MEMBER FUNCTION getNumber RETURN FLOAT
EXTERNAL NAME 'getNumber() return double',
STATIC FUNCTION getStaticNumber(xp FLOAT, yp FLOAT, zp FLOAT) RETURN FLOAT
EXTERNAL NAME 'getStaticNumber(double, double, double) return double')
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
After that I tried some SQL commands:
create table pointsj of point3dj;
insert into pointsj values (point3dj(2,1,1));
SELECT x, a.getnumber() FROM pointsj a;Now, the problem:
Everything works fine, if I delete the constructor
public Point3dj(double x, double y, double z)
this.x = x;
this.y = y;
this.z = z;
in the java class, or if I replace it with a constructor that has no input arguments.
But with this few code lines in the java file, I get an error when executing the SQL command
SELECT x, a.getnumber() FROM pointsj a;The Error is:
"ORA-00932: inconsistent data types: an IN argument at position 1 that is an instance of an Oracle type convertible to an instance of a user defined Java class expected, an Oracle type that could not be converted to a java class received"
I think, there are some problems with the input argument of the constructor, but why? I don't need the constructor in SQL, but it is used by a routine of another java class, so I can't just delete it.
Can anybody help me? I would be very glad about that since I already tried a lot and also search in forums and so on, but wasn't successful up to new.
Thanks!

Dear Avi,
This makes sense when it is a short code sample (and i think i've done that across various posts), but sometime this is too long to copy/paste, in these cases, i refer to the freely available code samples, as i did above on this forum; here is the quote.
Look at examples of VARRAY and Nested TABLES of scalar types in the code samples of my book (chapter 8) http://books.elsevier.com/us//digitalpress/us/subindex.asp?maintarget=companions/defaultindividual.asp&isbn=9781555583293&country=United+States&srccode=&ref=&subcode=&head=&pdf=&basiccode=&txtSearch=&SearchField=&operator=&order=&community=digitalpress
As you can see, i was not even asking people to buy the book, just telling them where to grab the code samples.
I appreciate your input on this and as always, your contribution to the forum, Kuassi

Oracle 10g Insert query performs inconsistent as a query vs procedure and p

Database Version: Oracle Database 10g Enterprise Edition Release 10.2.0.3.0 - 64bi
No error messages....
I am facing a very weird issue that I have a insert statement in a procedure... pretty much
inert
into oracle_Table
SELECT cr.a AS a,
cr.b AS b,
cr.c AS c,
max(d.column_name) as d
FROM "table 1"@Pmo.World Cr,
[email protected] d
WHERE d."a" = cr."column name"
GROUP BY cr.a,
cr.b,
cr.c
@Pmo.World is a database link to a MSSQL...
The problem I am having right now is, every time I run this insert as a query. Everything works as what it should be... However, when I put this insert into a procedure, it inserts nothing...
Simple test Proceudre:
declare
-- Local variables here
i integer;
begin
inert
into oracle_Table
SELECT cr.a AS a,
cr.b AS b,
cr.c AS c,
max(d.column_name) as d
FROM "table 1"@Pmo.World Cr,
[email protected] d
WHERE d."a" = cr."column name"
GROUP BY cr.a,
cr.b,
cr.c
end;
Thinking about character conversion issue I changed the procedure to
inert
into oracle_Table
SELECT to_char(cr.a) AS a,
to_char(cr.b) AS b,
to_char(cr.c) AS c,
max(d.column_name) as d
FROM "table 1"@Pmo.World Cr,
[email protected] d
WHERE d."a" = cr."column name"
GROUP BY cr.a,
cr.b,
cr.c
Then this Inser works in the procedure... however when I revert it back with the original version that doesnt have to_char... it is working still... then I kept it running for few days... since it runs once per day, it was working for the first 2 days and then stopped working the third day... I verified the source table and every time this procedure runs, source tables were not empty...
It is so confusing because if I manually run the insert as a query, it worked every time I ran it... however if I put that into a procedure, it works from time to time..
Any help is highly apprecaited
Edited by: 986006 on Feb 4, 2013 8:51 AM

986006 wrote:
Thanks for the hints up... I have updated my post... As I post the test procedure...it is about the exact the same as the insert query... Every time, the insert would actually insert data into the table but every time I run the test procedure, nothing gets inserted in... It sounds unbelievable but it happens... ThanksYou obviously haven't read the FAQ, or at least you haven't bothered doing what it asks. Help us to help you.
Can you recreate the problem with simpler data on your local machine? If so provide create table and insert statements for test data.
Format your code and place between tags.
At the very least post the *exact* SQL or PL/SQL you are trying to run: what you've posted isn't even valid SQL.

Inconsistent query performance

my query is this:
select hz, hz_time from freq_logger where hz_time = (select max(hz_time) from freq_logger)
hz is a float, hz_time is a timestamp that is based on the time the row is inserted. After about a million rows inserted I started noticing slow down in the app that uses this query. I went to toad and the query is executing at 125-200ms, much more than the ~70ms it needs to be at for the app to run smoothly. However in sqlplus I got around 70ms. And then I noticed that another PC was running this exact app without any noticeable slow down. So I logged the query execution within the app, on my PC it was at around 200ms while the other PC was at 70ms. Any ideas what could be causing this performance difference?
thanks

No
Your watch is an inadequate analysis instrument. Moreover you don't adhere to the following to posts
When your query takes too long ...
and
HOW TO: Post a SQL statement tuning request - template posting
so can not be worked upon.
Sybrand Bakker
Senior Oracle DBA

User Administration behaving inconsistently,while Querying!

Hi,
I have installed a new EP6 SP9 instance with SR1 CD.I have also installed content management and collaboration.
At the time of installation I got no error at all.The Portal,was installed and I was able to view the different feature in Portal.
But,when I make a query for role(under User Adminstration),sometimes I get the result and sometimes,I see the following error message:Internet open the internet site http://......,i.e.the Portal url/irj/portal.Can you please tell me what I am to do and why this happens.This does not happen always even for the same query like when I search for a user under roles of User Administration.

There are UME bugs in SPS 9. I have Upgraded to SPS 11 Patch 3 and those bugs are gone. MAKE SURE YOUE SAVE YOUR UME SETTINGS! I lost them in the upgrade. All user mappings, custom front page, GONE. READ THE NOTES!
SPS 12 is out. I'm staying here at Patch 3 SPS 11 until I have to move, it is very stable and it fixed the bugs I had at SPS 9.

Mind Boggling Problem: Inconsistent behaviour of a Simple Query

Hi All,
I am faced with a with a mind boggling problem, i have designed a query in BEx Query designer, the query is a rather simple one taking date as input and returning two fields one in carton the other in litres (the conversion is a simple formula) on that date. The problem is when i run this query (using BEx Analyzer) on a date for instance 10th of October, the first time it is run it gives the correct result but when i run it again on the same date i.e. 10th of October it gives incorrect result. To fix this i close the Analyzer log off then log on again and then run the query to get correct data; sometimes this works sometimes doesnt.
I am puzzled pls pls help any one...
Regards,
FS

Check if the issue with query is also present when you run query in RSRT in SAPGUI. You can also review the cache settings in RSRT

RMAN - Query on V$BACKUP_SET inconsistency

Hi friends,
Oracle Database EE 11.2.0.2 on Solaris 10...
We have incremental level 0 backups which runs on Sunday using command
backup as compressed backupset incremental level 0 .....
We have incremental level 1 backups which runs everyday other than Sunday using command
backup as compressed backupset incremental level 1 database....
After the backup ran for today, what I see is as shown below..
SQL> select BACKUP_TYPE,INCREMENTAL_LEVEL,START_TIME,COMPLETION_TIME from v$backup_set where START_TIME > sysdate -4 and BACKUP_TYPE<>'L';
B INCREMENTAL_LEVEL START_TIME        COMPLETION_TIME
D                 0 28-AUG-2011 04:30 28-AUG-2011 04:33
D                 0 28-AUG-2011 04:30 28-AUG-2011 04:33
I                 1 29-AUG-2011 04:30 29-AUG-2011 04:33
I                 1 29-AUG-2011 04:30 29-AUG-2011 04:35
I                 1 30-AUG-2011 04:30 30-AUG-2011 04:33
I                 1 30-AUG-2011 04:30 30-AUG-2011 04:35
I                 1 31-AUG-2011 04:30 31-AUG-2011 04:33
I                 1 31-AUG-2011 04:30 31-AUG-2011 04:35
D                   31-AUG-2011 04:35 31-AUG-2011 04:35
D                   31-AUG-2011 06:30 31-AUG-2011 06:30
D                   31-AUG-2011 08:30 31-AUG-2011 08:30As per Oracle documentation V$BACKUP_SET,BACKUP_TYPE holds
"BACKUP_TYPE VARCHAR2(1) Type of files that are in this backup. If the backup contains archived redo logs, the value is L. If this is a datafile full backup, the value is D. If this is an incremental backup, the value is I."
"INCREMENTAL_LEVEL NUMBER Location where this backup set fits into the database's backup strategy. Set to zero for full datafile backups, nonzero for incremental datafile backups, and NULL for archivelog backups."
So the above query shows an entry with "D" which means a full datafile backup did run today, but you can see INCREMENTAL_LEVEL is null which means it is not a full datafile backup. My questions is, why is BACKUP_TYPE field showing not as per the documentation -Why it is showing a "D" ?
Listing the backup also does not show a full backup.
Thanks in Advance.
RMAN> list backup summary;
using target database control file instead of recovery catalog
List of Backups
===============
Key     TY LV S Device Type Completion Time #Pieces #Copies Compressed Tag
1722    B 0 A DISK        28-AUG-11       1       1       YES        DB_FULL_BACKUP
1723    B 0 A DISK        28-AUG-11       1       1       YES        DB_FULL_BACKUP
1724    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T043338
1727    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T063036
1729    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T083025
1731    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T103015
1733    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T123050
1735    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T143026
1737    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T163025
1739    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T183025
1741    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T203029
1743    B A A DISK        28-AUG-11       1       1       YES        TAG20110828T223027
1745    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T003025
1747    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T023043
1749    B 1 A DISK        29-AUG-11       1       1       YES        DB_INCR_BACKUP
1750    B 1 A DISK        29-AUG-11       1       1       YES        DB_INCR_BACKUP
1751    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T043543
1752    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T043543
1754    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T063027
1756    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T083027
1758    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T103035
1760    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T123054
1762    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T143043
1764    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T163029
1766    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T183036
1768    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T203026
1770    B A A DISK        29-AUG-11       1       1       YES        TAG20110829T223029
1772    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T003021
1774    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T023042
1776    B 1 A DISK        30-AUG-11       1       1       YES        DB_INCR_BACKUP
1777    B 1 A DISK        30-AUG-11       1       1       YES        DB_INCR_BACKUP
1778    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T043517
1779    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T043517
1781    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T063031
1783    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T083027
1785    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T103026
1787    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T123041
1789    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T143021
1791    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T163030
1793    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T183033
1795    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T203026
1797    B A A DISK        30-AUG-11       1       1       YES        TAG20110830T223027
1799    B A A DISK        31-AUG-11       1       1       YES        TAG20110831T003027
1801    B A A DISK        31-AUG-11       1       1       YES        TAG20110831T023048
1803    B 1 A DISK        31-AUG-11       1       1       YES        DB_INCR_BACKUP
1804    B 1 A DISK        31-AUG-11       1       1       YES        DB_INCR_BACKUP
1805    B A A DISK        31-AUG-11       1       1       YES        TAG20110831T043513
1806    B A A DISK        31-AUG-11       1       1       YES        TAG20110831T043513
1807    B F A DISK        31-AUG-11       1       1       NO         TAG20110831T043518
1808    B A A DISK        31-AUG-11       1       1       YES        TAG20110831T063015
1809    B F A DISK        31-AUG-11       1       1       NO         TAG20110831T063024
1810    B A A DISK        31-AUG-11       1       1       YES        TAG20110831T083026
1811    B F A DISK        31-AUG-11       1       1       NO         TAG20110831T083034Thanks in Advance,
SSN

Please see the details below.
ibs-ash-sr117 ora2g [ic2gprd1]:grep "input datafile file number" rman_incrbackup_310811.log
input datafile file number=00006 name=+DATA/ic2gprd/datafile/ico_2g.300.752046801
input datafile file number=00005 name=+DATA/ic2gprd/datafile/undotbs2.296.752043055
input datafile file number=00004 name=+DATA/ic2gprd/datafile/users.291.752042881
input datafile file number=00002 name=+DATA/ic2gprd/datafile/sysaux.289.752042881
input datafile file number=00007 name=+DATA/ic2gprd/datafile/icobill_2g.370.754999093
input datafile file number=00001 name=+DATA/ic2gprd/datafile/system.288.752042879
input datafile file number=00003 name=+DATA/ic2gprd/datafile/undotbs1.290.752042881
ibs-ash-sr117 ora2g [ic2gprd1]:grep "input datafile file number" rman_incrbackup_310811.log | wc -l
       7
SQL> select count(*) from dba_data_files ;
COUNT(*)
         7
SQL> select count(*),status from dba_tablespaces group by status;
COUNT(*) STATUS
         8 ONLINE
RMAN> show all;
using target database control file instead of recovery catalog
RMAN configuration parameters for database with db_unique_name IC2GPRD are:
CONFIGURE RETENTION POLICY TO REDUNDANCY 1;
CONFIGURE BACKUP OPTIMIZATION OFF; # default
CONFIGURE DEFAULT DEVICE TYPE TO DISK; # default
CONFIGURE CONTROLFILE AUTOBACKUP ON;
CONFIGURE CONTROLFILE AUTOBACKUP FORMAT FOR DEVICE TYPE DISK TO '/orabackup/ora2g/rman/controlfile/%F';
CONFIGURE DEVICE TYPE DISK PARALLELISM 2 BACKUP TYPE TO BACKUPSET;
CONFIGURE DATAFILE BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE ARCHIVELOG BACKUP COPIES FOR DEVICE TYPE DISK TO 1; # default
CONFIGURE MAXSETSIZE TO UNLIMITED; # default
CONFIGURE ENCRYPTION FOR DATABASE OFF; # default
CONFIGURE ENCRYPTION ALGORITHM 'AES128'; # default
CONFIGURE COMPRESSION ALGORITHM 'BASIC' AS OF RELEASE 'DEFAULT' OPTIMIZE FOR LOAD TRUE ; # default
CONFIGURE ARCHIVELOG DELETION POLICY TO NONE; # default
CONFIGURE SNAPSHOT CONTROLFILE NAME TO '/projects/ora2g/product/11.2.0/db_1/dbs/snapcf_ic2gprd1.f'; # default

Query returning inconsistent result at each execution

Hi All,
Does any 1 have an idea?.I have 2 tables with more than 60 lac records.In a query i have to inner join the 2 tables and there is a where clause.
select dsp.col2, s.col3
from table1 dsp inner join table2 s
on dsp.col1=s.col1
where dsp.col2='30-Jan-2009'
The query output used to work earlier but nowadays it seems the where clause is not working.The o/p is varied resultset.

What is your Oracle version?
It is working - (Off course in a small environment i've tested it. ;) )
satyaki>
satyaki>select * from v$version;
BANNER
Oracle Database 10g Enterprise Edition Release 10.2.0.1.0 - Prod
PL/SQL Release 10.2.0.1.0 - Production
CORE    10.2.0.1.0      Production
TNS for Linux: Version 10.2.0.1.0 - Production
NLSRTL Version 10.2.0.1.0 - Production
Elapsed: 00:00:00.00
satyaki>
satyaki>ed
Wrote file afiedt.buf
1 select e.ename, d.loc
2     from emp e inner join dept d
3     on ( e.deptno = d.deptno)
4* where e.hiredate < sysdate
satyaki>/
ENAME      LOC
WARD
MARTIN
SCOTT      NY
KING       KOLKATA
TURNER
ADAMS      NY
JAMES
FORD       NY
MILLER     KOLKATA
Smith      KOLKATA
Glen       KOLKATA
11 rows selected.
Elapsed: 00:00:00.00
satyaki>
satyaki>
satyaki>Regards.
Satyaki De.

Af:query inconsistency

Similar Messages

Maybe you are looking for