Bug: '--' in source query results in ORA-01008

All,
I got bit by a rather odd little bug this weekend. Apparently, APEX doesn't like it if you try to select a string containing two dashes (the SQL comment delimeter --) as the source of a page item, but only if your query includes a binding to another page item. I put a demonstration up at http://apex.oracle.com/pls/apex/f?p=16631:1. The value chosen in the select list doesn't matter; it's just there to be referenced in the queries used on pages 2 and 3.
Took me a while to realize what was going on. So, if you need to include two dashes as part of your selected values, use '-'||'-' (or some similar work-around). You'll save yourself some confusion.
-David

Arie,
Then both documents are seriously misleading. :-) From the document you linked:
<b>Tip:</b>
This section is current as of the writing of this document. To view the most current listing of known issues, go to the Known Issues page available off the Downloads page. See:
http://www.oracle.com/technetwork/developer-tools/apex/downloads/index.html
And from the latest version of the known issues linked on that page (which I linked to above):
Application Express 4.0.2 was released on November 19, 2010. It addressed most of the known issues with 4.0.1. Below are the remaining known issues and any new issues discovered.Combining those two statements leads to the clearly erroneous expectation that the four known issues on the 4.0.2 page are the only open ones.
-David

Similar Messages

BC4J bug with "bind variables" JBO-27122 ORA-01008

I think we are found a BUG using BC4J with bind variables in a view object.
If the bind variable appear in the WHERE condition two or more times at
the beginning of the query the above error occur.
oracle.jbo.SQLStmtException: JBO-27122: SQL error during statement preparation. Statement:
SELECT Emp.EMPNO,Emp.ENAME,Emp.JOB,Emp.MGR,Emp.HIREDATE,Emp.SAL,Emp.COMM, Emp.DEPTNO
FROM SCOTT.EMP Emp
WHERE :1 <=10000 and :1 <= sal and :2=20
java.sql.SQLException: ORA-01008: not all variables bound
Otherwise if bind variable apper two or more times, but not together
like this sample:
WHERE :1 <=10000 and :2=20 and :1 <= sal
the error not occur.
We prove this with:
JDeveloper 9.0.5.2 (build 1618)Business Components Version 9.0.5.16.0
JDeveloper 9.0.5.0 (build 1375)Business Components Version 9.0.5.13.52
I looking for a patch! or acceptable workaround.
Tx for your help!
diego.
/* the cliente app */
ApplicationModule am = Configuration.createRootApplicationModule("business_tier.AppModule","AppModuleLocal");
ViewObject vo = am.findViewObject("EmpView");
vo.setWhereClauseParam(0,"100");
vo.setWhereClauseParam(1,"20");
Row emp = vo.first();

This is a known bug (1326006). The workaround is to use:
vo.setWhereClauseParam(0,"100");
vo.setWhereClauseParam(1,"20");
vo.setWhereClauseParam(2,"20");
Hope this helps,
Lynn
Java Tools Team

In Procedure command, source query results not passed to target as # variables - why not?

Hi all,
I'm using ODI 11.1.1.6.0.
Has anyone had issues with this version with this feature?
I've just upgraded from 10.1.3.4.5.6_02 and feature doesn't work at all (not even in new procedures!) in my repository.
I've even tried creating a brand new repository then creating a new data server, new physical schema, new logical schema, mapped physical schema to the logical schema, and created a new procedure that does:-
Source tab (Oracle): SELECT scen_name FROM snp_scen
Target tab (ODI Tools): OdiStartScen -SCEN_NAME=DUMMY -SESSION_NAME=#scen_name
The session that's created has the name "#scen_name" and not the name from the result of the source query.
The DUMMY scenario is just generated from another procedure that has a single OdiSleep command.
Any ideas chaps?

Yet another bug...
Fixed in 11.1.1.6.4.

ORA-12801: error signaled in parallel query server P001 and ORA-01008:

I am trying to refresh a refresh group i am getting the below error. This refresh group is on a database RIO12. All Mviews on this database point to target database - TRIO23 (which has master tables) using database link. The refresh group has 21 Mviews. Mview ACCOUNT is one of them i am getting the below error.
BEGIN dbms_refresh.refresh('PLATS.PLATS_RG'); END;
ERROR at line 1:
ORA-12048: error encountered while refreshing materialized view "PLATS"."ACCOUNT"
ORA-12801: error signaled in parallel query server P001
ORA-01008: not all variables bound
ORA-02063: preceding 2 lines from TRIO23
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2254
ORA-06512: at "SYS.DBMS_SNAPSHOT", line 2460
ORA-06512: at "SYS.DBMS_IREFRESH", line 683
ORA-06512: at "SYS.DBMS_REFRESH", line 195
ORA-06512: at line 1
TRIO23 is oracle version 10.2.0.5.0, RIO12 is oracle version 10.2.0.3.0
Refreshing PLATS_RG refresh group has no problems from last 2 years, other 20 MViews when executed manually they are refreshed. Please help me in resolving this error. Thanks.

Do you have cursor_sharing set to force or similar? if so then you may be hitting bug Bug 5863277. Please confirm with Oracle support.
thanks

ORA-01008 Error while executing VO Query

HI,
I have a VO to get the heirarchy for the selected Business. On selecting appropriate business, ppr is fired to build up available heirarchies for that business. The query for VO is
SELECT pos.name ||' ('||DECODE(pos.primary_structure_flag,'Y','Primary', 'N', 'Non-Primary','')||')' name , posv.org_structure_version_id org_structure_version_id
FROM per_organization_structures pos,per_org_structure_versions posv
WHERE pos.business_group_id = :1
AND pos.organization_structure_id = posv.organization_structure_id
AND pos.business_group_id = posv.business_group_id
AND posv.date_to IS NULL
While executing the query, it throws ORA-01008 exception saying "Not all Variables are bound". During debugging i saw that the selected business group id is available in AM before calling the VO execution.
Any help will be appreciated.
Thanks,

Hi Tapash,
The following is the information you have requested
1. VO defn from the xml file
<?xml version="1.0" encoding='windows-1252'?>
<!DOCTYPE ViewObject SYSTEM "jbo_03_01.dtd">
<ViewObject
Name="HierarchyVO"
BindingStyle="Oracle"
CustomQuery="true"
RowClass="ge.oracle.apps.per.orghierarchy.poplist.server.HierarchyVORowImpl"
ComponentClass="ge.oracle.apps.per.orghierarchy.poplist.server.HierarchyVOImpl"
MsgBundleClass="oracle.jbo.common.JboResourceBundle"
UseGlueCode="false" >
<SQLQuery><![CDATA[
SELECT pos.name ||' ('||DECODE(pos.primary_structure_flag,'Y','Primary', 'N', 'Non-Primary','')||')' name , posv.org_structure_version_id org_structure_version_id
FROM per_organization_structures pos,per_org_structure_versions posv
WHERE pos.business_group_id = :1
AND pos.organization_structure_id = posv.organization_structure_id
AND pos.business_group_id = posv.business_group_id
AND posv.date_to IS NULL
]]></SQLQuery>
<DesignTime>
<Attr Name="_isCodegen" Value="true" />
<Attr Name="_version" Value="9.0.3.12.53" />
<Attr Name="_CodeGenFlagNew" Value="36" />
</DesignTime>
<ViewAttribute
Name="Name"
IsPersistent="false"
Precision="44"
Type="java.lang.String"
AliasName="NAME"
ColumnType="VARCHAR2"
Expression="NAME"
SQLType="VARCHAR" >
<DesignTime>
<Attr Name="_DisplaySize" Value="44" />
</DesignTime>
</ViewAttribute>
<ViewAttribute
Name="OrgStructureVersionId"
IsPersistent="false"
IsNotNull="true"
Type="oracle.jbo.domain.Number"
AliasName="ORG_STRUCTURE_VERSION_ID"
ColumnType="VARCHAR2"
Expression="ORG_STRUCTURE_VERSION_ID"
SQLType="NUMERIC" >
<DesignTime>
<Attr Name="_DisplaySize" Value="22" />
</DesignTime>
</ViewAttribute>
</ViewObject>
2. the method in AM
public void getHierarchy(String strBusinessGrpId)
try
HierarchyVOImpl vo = getHierarchyVO1();
Number BusinessGroupId = new Number("0");
if(strBusinessGrpId!=null && !strBusinessGrpId.equals(""))
BusinessGroupId = new Number(strBusinessGrpId);
//vo.setWhereClause(null);
//vo.setWhereClauseParam(0,BusinessGroupId);
vo.executeQuery();
catch(Exception e)
throw new OAException(e.toString(),OAException.ERROR);
} //end of getHierarchy
3. calling code in CO
if ("changeBusiness".equals(pageContext.getParameter(OAWebBeanConstants.EVENT_PARAM)))
String businessGrpId = pageContext.getParameter("BusinessGroup");
Serializable[] parameters = { businessGrpId };
mAM.invokeMethod("handleChangeBusiness", parameters);
mAM.invokeMethod("getHierarchy", parameters);
Thanks,
Mohammadi

Bug? ORA-01008: not all variables bound when using DB LINK

This SQL runs fine in SQL*Plus but returns ORA-01008 in Apex.
If I replace the bind variable with a literal, it works fine in Apex.
Using OracleXE 10.2.0.1.0, Apex 2.1.0.00.39
with ixc as (
     select ic.table_name, ic.index_name, ic.column_name, ic.column_position
     from user_indexes@MY_DB_LINK ix
     join user_ind_columns@MY_DB_LINK ic
     on   (
          ic.index_name    = ix.index_name
          and
          ic.table_name     = ix.table_name
select
pk.table_name as pk_table
, fk.table_name as fk_table
, ucc.position
, ucc.column_name
, nvl(ixc.index_name,'-- not indexed --') as indexed
, ixc.column_position as ind_position
from (select table_name, owner, constraint_name, r_constraint_name, r_owner from user_constraints@MY_DB_LINK) fk
join (select table_name, owner, constraint_name from user_constraints@MY_DB_LINK) pk
on   (
     fk.r_owner = pk.owner
     and
     fk.r_constraint_name = pk.constraint_name
join user_cons_columns@MY_DB_LINK ucc
on   (
     ucc.owner           = fk.owner
     and
     ucc.constraint_name = fk.constraint_name
     and
     ucc.table_name      = fk.table_name
left join ixc
on   (
     ixc.column_name = ucc.column_name
     and
     ixc.table_name = fk.table_name
where pk.table_name like upper(:P11_TABLE_NAME)
order by pk.table_name, fk.table_name, index_name, ucc.position

one small advice....
SQL95 semantics is something that is new in Oracle (from 9 version)....so maybe if you try to write your query with standard "=" "=+" join signs...
I know that if that is part of universal app (SQL comaptible) that soem aditional problems may occure...but just try and look at the result...

Bug in pinning of results tabs results in multiple query results tabs

In Tools > Preferences > Database > Worksheet there is an option called Automatically Freeze Reult Tabs.
This option, when unchecked, does not seem to be working. New query results tabs are created when pressing F9 to run selected query text.
Elsewhere I have read that this is a known bug (9247525). A work-around is said to be to not select text before pressing F9. However, this does not seem to always work for me. Sometimes SQL Developer tries to execute code that is outside of the immediate query. The result is usually a query error.
Thus a whole bunch of query result tabs build up.
Is this bug being addressed? Is there a place where these bugs can be looked up? Or that status of a bug checked?
Thanks for any assistance.
(I am on 2.1.0.63. On Windows.)
--Michael

The bug you have found will be somewhere in the list of work for the SQL Developer team and should get fixed and included in a public release/patch eventually.
It sounds like your issue with the workaround (statement being identified based on cursor position) is with SQL Developer's pickiness with what is the end of a statement. As a general rule, SQL Developer will only consider a ; at the end of a line or a / starting a new line as the end of a statement - it does not consider a blank line the end of a statement. For example, the following is all considered a single statement:
select * from dual
select * from dual;theFurryOne

ORA-01008 on SQL Query

Hello from IOUG-A!!
OK, I have a SQL Query updatable report region that I've written the following SQL for:
select per_name, per_address_line1, per_town, per_isle_code, per_cntry_code
from gen_persons
where
(per_last_name like nvl(v(:P4200_LAST_NAME),
'---')||'%' ) and
(per_first_name like nvl(v(:p4200_FIRST_NAME),
'---')||'%')
) or
per_name like nvl(v(:P4200_LAST_NAME),
'---')||'%' )
This works great as long as P4200_FIRST_NAME is not NULL. If P4200_FIRST_NAME is NULL, I get the following error when I run the report:
report error:
ORA-01008: not all variables bound
My guess is that this is because of the NVL replacement and P3200_FIRST_NAME that is taking place, but I'm not sure how to fix it. Any ideas?
Robert

Robert,
Change '--' to '-'||'-'. Our parser thinks '--' is the beginning of a line comment.
Scott

Compounded source system shows in query results

Hi All,
I have characteristics compounded with 0soursystem. In query results it shows P1/SA01, for example. I want to truncate so it will only show SA01 and NOT the source system id P1. How do you do this?
Cheers,
Mike

Dear Mike,
I would like to do exactly the same thing, but untill now without success. The 0SOURSYSTEM is displayed in query as part of key of characteristic to which it is compounded.
Could you describe in detail what you have done and context?
Thanks in advance,
Josko.

Bug SQL Dev 1.5.4 Build MAIN-5940 Exporting count(*) query results

when trying to export query results containing an analytic count the export dialog fails to open:
When running the following query
select count(*) over (partition by dummy order by rownum) xx
from dual;right clicking on the results grid and selecting export->xls (or any other format) fails to open the export dialog box.
changing the asterisk (*) to another value e.g. 1 or dummy corrects this issue for this particular query as does changing the analytic fuction to an aggregate function.
Edited by: Sentinel on Aug 12, 2009 11:05 AM

I get the same error when exporting the same statement - however, there is a known problem with 1.5.4 and failing on exports of certain statements (see 1.5.3 - Export results to XLS ORA-00936 which talks about there still being problems in 1.5.4 although the thread is titled 1.5.3).
theFurryOne

Bug: the query results dialog extends outside the screen boundaries

Hi, I observed this bug on MacOS 10.5.5 running Eclipse 3.4.1 with FlexBuilder 3.0.2 installed. Steps to repro:
1. make FlexBuilder full screen
2. open an MXML document
3. make the editor full screen (double-click the editor's tab)
4. select in the text editor the name of a Flex SDK class (e.g. Window, Button, ...)
5. scroll the editor window so that the selected text is near the bottom of the screen
5. click the Blueprint button, or type ctrl-B
Result: the Blueprint query results window is only partly visible, most of it is below the bottom of the screen
Expected: the query results window auto-positions itself to be fully visible

Thanks for trying out Blueprint and giving us feedback!
We have filed a ticket for this bug and will do our best to address it in the next release!
Mira Dontcheva
Research Scientist
Adobe Systems

ORA-01008 with ref cursor and dynamic sql

When I run the follwing procedure:
variable x refcursor
set autoprint on
begin
Crosstab.pivot(p_max_cols => 4,
   p_query => 'select job, count(*) cnt, deptno, row_number() over (partition by job order by deptno) rn from scott.emp group by job, deptno',
   p_anchor => Crosstab.array('JOB'),
   p_pivot => Crosstab.array('DEPTNO', 'CNT'),
   p_cursor => :x );
end;I get the following error:
^----------------
Statement Ignored
set autoprint on
begin
adsmgr.Crosstab.pivot(p_max_cols => 4,
p_query => 'select job, count(*) cnt, deptno, row_number() over (partition by
p_anchor => adsmgr.Crosstab.array('JOB'),
p_pivot => adsmgr.Crosstab.array('DEPTNO', 'CNT'),
p_cursor => :x );
end;
ORA-01008: not all variables bound
I am running this on a stored procedure as follows:
create or replace package Crosstab
as
    type refcursor is ref cursor;
    type array is table of varchar2(30);
    procedure pivot( p_max_cols       in number   default null,
                     p_max_cols_query in varchar2 default null,
                     p_query          in varchar2,
                     p_anchor         in array,
                     p_pivot          in array,
                     p_cursor in out refcursor );
end;
create or replace package body Crosstab
as
procedure pivot( p_max_cols          in number   default null,
                 p_max_cols_query in varchar2 default null,
                 p_query          in varchar2,
                 p_anchor         in array,
                 p_pivot          in array,
                 p_cursor in out refcursor )
as
    l_max_cols number;
    l_query    long;
    l_cnames   array;
begin
    -- figure out the number of columns we must support
    -- we either KNOW this or we have a query that can tell us
    if ( p_max_cols is not null )
    then
        l_max_cols := p_max_cols;
    elsif ( p_max_cols_query is not null )
    then
        execute immediate p_max_cols_query into l_max_cols;
    else
        RAISE_APPLICATION_ERROR(-20001, 'Cannot figure out max cols');
    end if;
    -- Now, construct the query that can answer the question for us...
    -- start with the C1, C2, ... CX columns:
    l_query := 'select ';
    for i in 1 .. p_anchor.count
    loop
        l_query := l_query || p_anchor(i) || ',';
    end loop;
    -- Now add in the C{x+1}... CN columns to be pivoted:
    -- the format is "max(decode(rn,1,C{X+1},null)) cx+1_1"
    for i in 1 .. l_max_cols
    loop
        for j in 1 .. p_pivot.count
        loop
            l_query := l_query ||
                'max(decode(rn,'||i||','||
                           p_pivot(j)||',null)) ' ||
                            p_pivot(j) || '_' || i || ',';
        end loop;
    end loop;
    -- Now just add in the original query
    l_query := rtrim(l_query,',')||' from ( '||p_query||') group by ';
    -- and then the group by columns...
    for i in 1 .. p_anchor.count
    loop
        l_query := l_query || p_anchor(i) || ',';
    end loop;
    l_query := rtrim(l_query,',');
    -- and return it
    execute immediate 'alter session set cursor_sharing=force';
    open p_cursor for l_query;
    execute immediate 'alter session set cursor_sharing=exact';
end;
end;
/I can see from the error message that it is ignoring the x declaration, I assume it is because it does not recognise the type refcursor from the procedure.
How do I get it to recognise this?
Thank you in advance

Thank you for your help
This is the version of Oracle I am running, so this may have something to do with that.
Oracle9i Enterprise Edition Release 9.2.0.8.0 - Production
With the Partitioning, OLAP and Oracle Data Mining options
JServer Release 9.2.0.8.0 - Production
I found this on Ask Tom (http://asktom.oracle.com/pls/asktom/f?p=100:11:0::::P11_QUESTION_ID:3027089372477)
Hello, Tom.
I have one bind variable in a dynamic SQL expression.
When I open cursor for this sql, it gets me to ora-01008.
Please consider:
Connected to:
Oracle8i Enterprise Edition Release 8.1.7.4.1 - Production
JServer Release 8.1.7.4.1 - Production
SQL> declare
2    type cur is ref cursor;
3    res cur;
4 begin
5    open res for
6    'select * from (select * from dual where :p = 1) connect by 1 = 1'
7    using 1;
8 end;
9 /
declare
ERROR at line 1:
ORA-01008: not all variables bound
ORA-06512: at line 5
SQL> declare
2    type cur is ref cursor;
3    res cur;
4 begin
5    open res for
6    'select * from (select * from dual where :p = 1) connect by 1 = 1'
7    using 1, 2;
8 end;
9 /
PL/SQL procedure successfully completed.
And if I run the same thing on 10g -- all goes conversely. The first part runs ok, and the second
part reports "ORA-01006: bind variable does not exist" (as it should be, I think). Remember, there
is ONE bind variable in sql, not two. Is it a bug in 8i?
What should we do to avoid this error running the same plsql program code on different Oracle
versions?
P.S. Thank you for your invaluable work on this site.
Followup   June 9, 2005 - 6pm US/Eastern:
what is the purpose of this query really?
but it would appear to be a bug in 8i (since it should need but one). You will have to work that
via support. I changed the type to tarray to see if the reserved word was causing a problem.
variable v_refcursor refcursor;
set autoprint on;
begin
     crosstab.pivot (p_max_cols => 4,
             p_query =>
               'SELECT job, COUNT (*) cnt, deptno, ' ||
               '       ROW_NUMBER () OVER ( ' ||
               '          PARTITION BY job ' ||
               '          ORDER BY deptno) rn ' ||
               'FROM   emp ' ||
               'GROUP BY job, deptno',
               p_anchor => crosstab.tarray ('JOB'),
               p_pivot => crosstab.tarray ('DEPTNO', 'CNT'),
               p_cursor => :v_refcursor);
end;
/Was going to use this package as a stored procedure in forms but I not sure it's going to work now.

Query result closing prematurely, Object closed error

Hi guys
I've discovered an unusual behaviour when iterating through a collection
returned from a query.
Scenario
The code executes a query, iterates partially through the resultset and for
each row calls a method which creates another object. Given that there
could be thousands of rows, I commit the new objects every n times and then
go back to the start of the loop which re-executes the query. This code runs
fine when
MAX_SCHEDULES_PER_TRANS <= com.solarmetric.kodo.DefaultFetchBatchSize.
Problem
If the DefaultFetchBatchSize is 10, and I commit every 11 iterations, then
during the 3rd outer loop (ie commit has succeeded twice and the query has
been executed 3 times) an exception is thrown when calling events.next() on
the 10th element. The stack trace is included below, but it appears that
the query resultset is somehow being closed early.
If I increase the DefaultFetchBatchSize to 20, then I can also increase my
MAX_SCHEDULES_PER_TRANS to 20 without getting the error.
Any ideas?
Regards
Nathan
Kodo 2.5.3
SQLServer 2000
Code Snippet
private static final int MAX_SCHEDULES_PER_TRANS = 10;
while (!terminated) {
Collection col = (Collection) getQuery().execute(currentDate); //
getQuery() method Creates query object once and reused in subsequent calls
Iterator events = col.iterator();
int counter = 0;
boolean committed = false;
while (events.hasNext() && !committed && !terminated) {
Event event = (Event) events.next();
event.schedule()
counter++;
if ((counter == MAX_SCHEDULES_PER_TRANS ) || !events.hasNext()) {
try {
context.getPersist().commitTransaction();
committed = true;
catch (OptimisticLockException e) {
context.getPersist().rollbackTransaction();
break;
getQuery().close(col);
Kodo.properties
# Kodo JDO Properties configuration
# DEVELOPMENT
com.solarmetric.kodo.LicenseKey: xxxxxxx
com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerName=Tran
sactionFactory
javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.JDBC
PersistenceManagerFactory
javax.jdo.option.ConnectionDriverName=com.microsoft.jdbc.sqlserver.SQLServer
Driver
javax.jdo.option.ConnectionUserName=xxxxx
javax.jdo.option.ConnectionPassword=xxxx
javax.jdo.option.ConnectionURL=jdbc:microsoft:sqlserver://devsnetsql01:1433;
SelectMethod=cursor;DatabaseName=devsnet09
javax.jdo.option.RetainValues=true
javax.jdo.option.RestoreValues=true
javax.jdo.option.Optimistic=true
javax.jdo.option.NontransactionalWrite=false
javax.jdo.option.NontransactionalRead=true
javax.jdo.option.Multithreaded=true
javax.jdo.option.MsWait=5000
javax.jdo.option.MinPool=0
javax.jdo.option.MaxPool=0
javax.jdo.option.IgnoreCache=false
com.solarmetric.kodo.FlushBeforeQueries=with-connection
com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory=20
com.solarmetric.kodo.impl.jdbc.StatementCacheMaxSize=0
com.solarmetric.kodo.impl.jdbc.WarnOnPersistentTypeFailure=true
com.solarmetric.kodo.impl.jdbc.SequenceFactoryClass=com.solarmetric.kodo.imp
l.jdbc.schema.DBSequenceFactory
com.solarmetric.kodo.impl.jdbc.FlatInheritanceMapping=true
com.solarmetric.kodo.impl.jdbc.AutoReturnTimeout=10
com.solarmetric.kodo.Logger=stdout
com.solarmetric.kodo.EnableQueryExtensions=true
com.solarmetric.kodo.DefaultFetchThreshold=30
com.solarmetric.kodo.DefaultFetchBatchSize=10
com.solarmetric.kodo.impl.jdbc.TransactionIsolation=READ_COMMITTED
com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerMethod=co
m.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager
com.solarmetric.kodo.ee.ManagedRuntimeClass=com.solarmetric.kodo.ee.Invocati
onManagedRuntime
Stack trace
com.solarmetric.kodo.runtime.DataStoreException: java.sql.SQLException:
[Microsoft][SQLServer 2000 Driver for JDBC]Object has been closed.
[code=0;state=HY000]
NestedThrowables:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Object has
been closed.
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore(SQLExcep
tions.java:64)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:223)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:431)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
at com.mallesons.servicenet.ta.shared.BOIterator.next(BOIterator.java:48)
at
com.mallesons.servicenet.ta.event.SchedulerThread.process(Scheduler.java:171
at com.mallesons.servicenet.ta.event.SchedulerThread.run(Scheduler.java:122)
NestedThrowablesStackTrace:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Object has
been closed.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown
Source)(Inlined Compiled Code)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown
Source)(Inlined Compiled Code)
at com.microsoft.jdbc.base.BaseConnection.validateClosedState(Unknown
Source)(Inlined Compiled Code)
at com.microsoft.jdbc.base.BaseStatement.validateClosedState(Unknown
Source)(Inlined Compiled Code)
at com.microsoft.jdbc.base.BaseResultSet.validateClosedState(Unknown
Source)(Compiled Code)
at com.microsoft.jdbc.base.BaseResultSet.getRow(Unknown Source)
at
com.solarmetric.datasource.ResultSetWrapper.getRow(ResultSetWrapper.java:465
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:186)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:431)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
at com.mallesons.servicenet.ta.shared.BOIterator.next(BOIterator.java:48)
at
com.mallesons.servicenet.ta.event.SchedulerThread.process(Scheduler.java:171
at com.mallesons.servicenet.ta.event.SchedulerThread.run(Scheduler.java:122)

Thanks for pointing out the optimisticLockException catch error. That would
have been a bug but it hasn't been hit yet as I've only ever run one
instance of this app!!
The BOIterator is just wrapper layer and I have removed it to ensure it is
not the culprit. Still getting the same error.
I have done some more testing and have narrowed down the problem a little.
It seems to only occur when I update one of the columns that is being used
in the query. If I update a column that is not used in the query, it works
fine.
com.solarmetric.kodo.runtime.DataStoreException: java.sql.SQLException:
[Microsoft][SQLServer 2000 Driver for JDBC]Object has been closed.
[code=0;state=HY000]
NestedThrowables:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Object has
been closed.
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore(SQLExcep
tions.java:64)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:223)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:431)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
at
com.mallesons.servicenet.ta.event.SchedulerThread.process(Scheduler.java:197
at com.mallesons.servicenet.ta.event.SchedulerThread.run(Scheduler.java:143)
NestedThrowablesStackTrace:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver for JDBC]Object has
been closed.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown Source)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown Source)
at com.microsoft.jdbc.base.BaseConnection.validateClosedState(Unknown
Source)
at com.microsoft.jdbc.base.BaseStatement.validateClosedState(Unknown Source)
at com.microsoft.jdbc.base.BaseResultSet.validateClosedState(Unknown Source)
at com.microsoft.jdbc.base.BaseResultSet.getRow(Unknown Source)
at
com.solarmetric.datasource.ResultSetWrapper.getRow(ResultSetWrapper.java:478
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:186)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:431)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
at
com.mallesons.servicenet.ta.event.SchedulerThread.process(Scheduler.java:197
at com.mallesons.servicenet.ta.event.SchedulerThread.run(Scheduler.java:143)
2003-10-27 15:26:40,142 DEBUG - SchedulerThread.run() - exit
"Marc Prud'hommeaux" <[email protected]> wrote in message
news:[email protected]...
Nathan-
I guess you are right that it doesn't look like the query result is
being kept open between commits. I do notice that the block that catches
the OptimisticLockException doesn't break out of the loop though: can
you check to ensure that one isn't getting thrown?
Also, what is the com.mallesons.servicenet.ta.shared.BOIterator stuff?
If it is a wrapper layer that you have around the query execution,
can you try removing it, just to ensure that it isn't misbehaving in
some way?
In article <[email protected]>, nathan boyes wrote:
Hi Marc,
Bug 718 certainly seems similar, however I still don't think it is
necessarily the problem in this case. That particular bug relates to the
resultset that was opened prior to commit, not remaining open after the
commit. However, once I've committed, I call query.closeAll() then re
execute the query. I would expect this to give me a new resultset that
would not be affected by the previous commit.
Also the CURSOR_CLOSE_ON_COMMIT is disabled by default and we haven't
enabled it. A query against the database using one of the SQLServer
functions confirms that this setting is false on the server.
Predictably, instantiating the entire collection also fixes the problem.
I
guess this is similar to setting DefaultFetchThreshold = -1.
Not really sure what else to try.
"Marc Prud'hommeaux" <[email protected]> wrote in message
news:[email protected]...
Nathan-
This sounds to me like
http://bugzilla.solarmetric.com/show_bug.cgi?id=718 , even though it is
not known to happen for SQLServer. If, before you commit, you
instantiate the entire "col" list (with something like
"new LinkedList (col)"), do you still see the problem?
If this is indeed the problem, it seems that this is a server option
that you can configure. If you disable CURSOR_CLOSE_ON_COMMIT on the
server, do you still see the problem? See:
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/tsqlref/ts_set-set_48kz.asp
>>>
>>>
>>>
>>>
In article <[email protected]>, nathan boyes wrote:
I have upgraded to 2.5.5 and am now calling query.closeAll() neither
of
which had any effect. When I set DefaultFetchThreshold to -1, thenthe
problem disappeared.
For efficiency, if I am iterating through 50 objects beforecommitting
then
it is probably worth setting
DefaultFetchThreshold=50
DefaultFetchBatchSize=50
which will run without problem.
However, that doesn't address the underlying problem that could stilloccur
in other parts of our system.
"Stephen Kim" <[email protected]> wrote in message
news:[email protected]...
First can you upgrade to Kodo 2.5.4 and see if the problem persists?
If so, can you for the sake of debugging try setting
DefaultFetchThreshold to -1?
Also you should be calling either query.closeAll () or query.close(events).
nathan boyes wrote:
Hi guys
I've discovered an unusual behaviour when iterating through a
collection
returned from a query.
Scenario
The code executes a query, iterates partially through the
resultset
and
for
each row calls a method which creates another object. Given that
there
could be thousands of rows, I commit the new objects every n timesand
then
go back to the start of the loop which re-executes the query. This
code
runs
fine when
MAX_SCHEDULES_PER_TRANS <=
com.solarmetric.kodo.DefaultFetchBatchSize.
Problem
If the DefaultFetchBatchSize is 10, and I commit every 11
iterations,
then
during the 3rd outer loop (ie commit has succeeded twice and the
query
has
been executed 3 times) an exception is thrown when calling
events.next()
on
the 10th element. The stack trace is included below, but it
appears
that
the query resultset is somehow being closed early.
If I increase the DefaultFetchBatchSize to 20, then I can also
increase
my
MAX_SCHEDULES_PER_TRANS to 20 without getting the error.
Any ideas?
Regards
Nathan
Kodo 2.5.3
SQLServer 2000
Code Snippet
private static final int MAX_SCHEDULES_PER_TRANS = 10;
while (!terminated) {
Collection col = (Collection) getQuery().execute(currentDate);
getQuery() method Creates query object once and reused insubsequent
calls
Iterator events = col.iterator();
int counter = 0;
boolean committed = false;
while (events.hasNext() && !committed && !terminated) {
Event event = (Event) events.next();
event.schedule()
counter++;
if ((counter == MAX_SCHEDULES_PER_TRANS ) ||
!events.hasNext()) {
>>>>>>
try {
context.getPersist().commitTransaction();
committed = true;
catch (OptimisticLockException e) {
context.getPersist().rollbackTransaction();
break;
getQuery().close(col);
Kodo.properties
# Kodo JDO Properties configuration
# DEVELOPMENT
com.solarmetric.kodo.LicenseKey: xxxxxxx
com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerName=Tran
sactionFactory
javax.jdo.PersistenceManagerFactoryClass=com.solarmetric.kodo.impl.jdbc.JDBC
PersistenceManagerFactory
javax.jdo.option.ConnectionDriverName=com.microsoft.jdbc.sqlserver.SQLServer
Driver
javax.jdo.option.ConnectionUserName=xxxxx
javax.jdo.option.ConnectionPassword=xxxx
javax.jdo.option.ConnectionURL=jdbc:microsoft:sqlserver://devsnetsql01:1433;
SelectMethod=cursor;DatabaseName=devsnet09
javax.jdo.option.RetainValues=true
javax.jdo.option.RestoreValues=true
javax.jdo.option.Optimistic=true
javax.jdo.option.NontransactionalWrite=false
javax.jdo.option.NontransactionalRead=true
javax.jdo.option.Multithreaded=true
javax.jdo.option.MsWait=5000
javax.jdo.option.MinPool=0
javax.jdo.option.MaxPool=0
javax.jdo.option.IgnoreCache=false
com.solarmetric.kodo.FlushBeforeQueries=with-connection
com.solarmetric.kodo.impl.jdbc.schema.DBSequenceFactory=20
com.solarmetric.kodo.impl.jdbc.StatementCacheMaxSize=0
com.solarmetric.kodo.impl.jdbc.WarnOnPersistentTypeFailure=true
com.solarmetric.kodo.impl.jdbc.SequenceFactoryClass=com.solarmetric.kodo.imp
l.jdbc.schema.DBSequenceFactory
com.solarmetric.kodo.impl.jdbc.FlatInheritanceMapping=true
com.solarmetric.kodo.impl.jdbc.AutoReturnTimeout=10
com.solarmetric.kodo.Logger=stdout
com.solarmetric.kodo.EnableQueryExtensions=true
com.solarmetric.kodo.DefaultFetchThreshold=30
com.solarmetric.kodo.DefaultFetchBatchSize=10
com.solarmetric.kodo.impl.jdbc.TransactionIsolation=READ_COMMITTED
com.solarmetric.kodo.ee.ManagedRuntimeProperties=TransactionManagerMethod=co
m.ibm.ejs.jts.jta.TransactionManagerFactory.getTransactionManager
com.solarmetric.kodo.ee.ManagedRuntimeClass=com.solarmetric.kodo.ee.Invocati
onManagedRuntime
Stack trace
com.solarmetric.kodo.runtime.DataStoreException:java.sql.SQLException:
[Microsoft][SQLServer 2000 Driver for JDBC]Object has been closed.
[code=0;state=HY000]
NestedThrowables:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver forJDBCObject
has
been closed.
at
com.solarmetric.kodo.impl.jdbc.runtime.SQLExceptions.throwDataStore(SQLExcep
tions.java:64)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:223)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:431)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
atcom.mallesons.servicenet.ta.shared.BOIterator.next(BOIterator.java:48)
>>>>>>
at
com.mallesons.servicenet.ta.event.SchedulerThread.process(Scheduler.java:171
atcom.mallesons.servicenet.ta.event.SchedulerThread.run(Scheduler.java:122)
>>>>>>
NestedThrowablesStackTrace:
java.sql.SQLException: [Microsoft][SQLServer 2000 Driver forJDBCObject
has
been closed.
at com.microsoft.jdbc.base.BaseExceptions.createException(Unknown
Source)(Inlined Compiled Code)
at com.microsoft.jdbc.base.BaseExceptions.getException(Unknown
Source)(Inlined Compiled Code)
at
com.microsoft.jdbc.base.BaseConnection.validateClosedState(Unknown
Source)(Inlined Compiled Code)
atcom.microsoft.jdbc.base.BaseStatement.validateClosedState(Unknown
Source)(Inlined Compiled Code)
atcom.microsoft.jdbc.base.BaseResultSet.validateClosedState(Unknown
Source)(Compiled Code)
at com.microsoft.jdbc.base.BaseResultSet.getRow(Unknown Source)
at
com.solarmetric.datasource.ResultSetWrapper.getRow(ResultSetWrapper.java:465
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.instantiateRow(LazyRes
ultList.java:186)
at
com.solarmetric.kodo.impl.jdbc.runtime.LazyResultList.get(LazyResultList.jav
a:142)
at java.util.AbstractList$Itr.next(AbstractList.java:431)
at
com.solarmetric.kodo.runtime.objectprovider.ResultListIterator.next(ResultLi
stIterator.java:49)
atcom.mallesons.servicenet.ta.shared.BOIterator.next(BOIterator.java:48)
>>>>>>
at
com.mallesons.servicenet.ta.event.SchedulerThread.process(Scheduler.java:171
atcom.mallesons.servicenet.ta.event.SchedulerThread.run(Scheduler.java:122)
>>>>>>
>>>>>>
>>>>>
Stephen Kim
[email protected]
SolarMetric, Inc.
http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com
Marc Prud'hommeaux [email protected]
SolarMetric Inc. http://www.solarmetric.com

Order of placeholders and bind variables (ORA-01008)

Hi, Everyone,
OS: Redhat Linux AS 3
Compiler : g++ 3.2.3
OCCI : 10.2
When a SELECT statement has more than 2 same placeholders,
I have experienced that stmt->executeQuery() throws SQLException (ORA-01008).
<case1>
std::string sql1 =
"SELECT str FROM tbl_sample WHERE col01 = :1 and col02 = :1 and col03 = :2";
stmt1->setInt(1, num1);
stmt1->setInt(2, num2);
ResultSet* rs = stmt1->executeQuery(); // NG. thrown ORA-01008
<case2>
std::string sql1 =
"SELECT str FROM tbl_sample WHERE col01 = :1 and col02 = :1 and col03 = :2";
stmt1->setInt(1, num1);
stmt1->setInt(2, num1);
stmt1->setInt(3, num2);
ResultSet* rs = stmt1->executeQuery(); // OK.
<case3>
std::string sql1 =
"SELECT str FROM tbl_sample WHERE col01 = :1 and col03 = :2 and col02 = :1";
stmt1->setInt(1, num1);
stmt1->setInt(2, num2);
ResultSet* rs = stmt1->executeQuery(); // OK.
In <case1>, I understand that the one line "stmt1->setInt(1, num1);" cannot bind two placeholders
(:1 of "WHERE col01 = :1 and col02 = :1 ") with the value of num1 simultaniously.
So, I have found that the code should be written in like <case2>.
But, in <case3>, the one line "stmt1->setInt(1, num1);" can bind two placeholders
(:1 of "col01 = :1 and col02 = :1") simultaniously!
The difference of <case1> and <case3> is the order of the placeholders (:1 and :2).
How should I understand this behavior?
I'm afraid that this is the bug of OCCI.
How do you think of it?
Thanks in advance.
Yoshitaka Egawa

Its not the complete query. I can't reproduce in 11106. Why you have subsiution variables shown here?
SQL> select * from V$version;
BANNER
Oracle Database 11g Enterprise Edition Release 11.1.0.6.0 - Production
PL/SQL Release 11.1.0.6.0 - Production
CORE    11.1.0.6.0      Production
TNS for 32-bit Windows: Version 11.1.0.6.0 - Production
NLSRTL Version 11.1.0.6.0 - Production
SQL> select empno from emp where empno in ( select anyno from dept);
select empno from emp where empno in ( select anyno from dept)
ERROR at line 1:
ORA-00904: "ANYNO": invalid identifier
SQL> desc emp
Name                                      Null?    Type
EMPNO                                     NOT NULL NUMBER(4)
ENAME                                              VARCHAR2(10)
JOB                                                VARCHAR2(9)
MGR                                                NUMBER(4)
HIREDATE                                           DATE
SAL                                                NUMBER(7,2)
COMM                                               NUMBER(7,2)
DEPTNO                                             NUMBER(2)
SQL> desc dept
Name                                      Null?    Type
DEPTNO                                    NOT NULL NUMBER(2)
DNAME                                              VARCHAR2(14)
LOC                                                VARCHAR2(13)
SQL>HTH
Aman....

How to force Work Item Query Policy to refresh its cached query results?

I have enabled the Work Item Query Policy on my TFS project. It works as expected, except when using Visual Studio 2013 with the following sequence of steps:
User selects Check in Pending Changes from the Source Control Explorer
User enters in the ID of the work item to be associated to the changeset
User clicks the Check In button
Work Item Query Policy displays message ' Work item ##### was not found in the results of stored query...'
User realizes his mistake, and modifies (and saves) the work item so that it is returned in in the query result set
User clicks the Check In button again expecting the TFS policy to accept the association
Work Item Query Policy still displays message ' Work item ##### was not found in the results of stored query...'
Removing the Work Item and re-associating it does not make a difference. The only workaround that I have found is to close Visual Studio and reopen it. Does any one have a better solution than this?

Our setup is different from the one you are using:
- User is using VS 2013 Update 4.
- We are running TFS 2010 SP1
The test case that you described is different from the one that is causing my problem (that scenario works fine for me as well). I am trying to associate the check in to the same work item both times; whereas, you are associating it to a different
work item the second time. I can consistently reproduce the error using the following steps:
1) Create a query that returns All Bugs in Active state, and set it as the query for the Work Item Query Policy
2) Create and save a new Bug
3) Run the query to confirm that the new bug does not appear in the result set
4) Checkout a file, modify it, save it
5) Check in the file and associate it to the bug from step 2)
- the Work Item Query Policy will issue an error message saying that the work item cannot be found in the associated query
6) Change the state of the bug to Active, and save
7) Refresh the query to confirm that the bug now appears in the result set
8) Check in the file again
- error message from step 5) will not go away

Bug: '--' in source query results in ORA-01008

Similar Messages

Maybe you are looking for