[ http://nagoya.apache.org/jira/browse/XALANJ-1908?page=history ]
Henry Zongaro updated XALANJ-1908:
----------------------------------
Assign To: (was: Xalan Developers Mailing List)
Description:
> SQLDocument.java line 407 execute returns false for this query:
>
> declare @InstKy int
> declare @MConKy int
> declare @Result int
> select @InstKy= -1
> select @MConKy= 1886524808
> exec @Result= ICntrTyOpn 1886524808
> , @InstKy output
> , @MConKy output
> , 1021
> , 2
> select @InstKy, @MConKy, @Result
That is kind of what I was expecting. The API Docs say that Execute returns
false if the execute is an Update or if the Query returns does not return a
result set. Not returning a results set is different than a query that returns
an empty result set. Can you explain what this SP is trying to do ?
I took a look at the 2.5.1 code and I see a subtile difference in how the
Query is executed. In 2.5.1 we were using executeQuery and not execute.
Can you try the following mod:
Orig Code:
m_Statement = conn.createStatement();
if (! m_Statement.execute(m_QueryParser.getSQLQuery()))
{
throw new SQLException("Error in Query");
}
New Code:
m_Statement = conn.createStatement();
m_ResultSet = m_Statement.executeQuery(m_QueryParser.getSQLQuery()))
return;
Yes the change (executeQuery) works for all the situations I tested.
Nearly all our stored procedures move data between a set of normalized tables of
permanent data and another set of denormalized tables with temporary data. A
whole bunch of overhead SQL is called as well, but no result sets are returned.
Separate queries select the temporary data.
Is the difference between execute and executeQuery going to break someone else's
use?
was:
> SQLDocument.java line 407 execute returns false for this query:
>
> declare @InstKy int
> declare @MConKy int
> declare @Result int
> select @InstKy= -1
> select @MConKy= 1886524808
> exec @Result= ICntrTyOpn 1886524808
> , @InstKy output
> , @MConKy output
> , 1021
> , 2
> select @InstKy, @MConKy, @Result
That is kind of what I was expecting. The API Docs say that Execute returns
false if the execute is an Update or if the Query returns does not return a
result set. Not returning a results set is different than a query that returns
an empty result set. Can you explain what this SP is trying to do ?
I took a look at the 2.5.1 code and I see a subtile difference in how the
Query is executed. In 2.5.1 we were using executeQuery and not execute.
Can you try the following mod:
Orig Code:
m_Statement = conn.createStatement();
if (! m_Statement.execute(m_QueryParser.getSQLQuery()))
{
throw new SQLException("Error in Query");
}
New Code:
m_Statement = conn.createStatement();
m_ResultSet = m_Statement.executeQuery(m_QueryParser.getSQLQuery()))
return;
Yes the change (executeQuery) works for all the situations I tested.
Nearly all our stored procedures move data between a set of normalized tables of
permanent data and another set of denormalized tables with temporary data. A
whole bunch of overhead SQL is called as well, but no result sets are returned.
Separate queries select the temporary data.
Is the difference between execute and executeQuery going to break someone else's
use?
Environment:
Operating System: All
Platform: All
was:
Operating System: All
Platform: All
Priority: Major
Bugzilla Id: (was: 30072)
Bug priority was lost in the move from Bugzilla to Jira.
> SQL Extension exec stored proc breaks between 2.5.1 and 2.5.2/2.6.0
> -------------------------------------------------------------------
>
> Key: XALANJ-1908
> URL: http://nagoya.apache.org/jira/browse/XALANJ-1908
> Project: XalanJ2
> Type: Bug
> Components: Xalan-extensions-(SQL), Xalan-interpretive
> Versions: 2.6
> Environment: Operating System: All
> Platform: All
> Reporter: Phil Friedman
>
> > SQLDocument.java line 407 execute returns false for this query:
> >
> > declare @InstKy int
> > declare @MConKy int
> > declare @Result int
> > select @InstKy= -1
> > select @MConKy= 1886524808
> > exec @Result= ICntrTyOpn 1886524808
> > , @InstKy output
> > , @MConKy output
> > , 1021
> > , 2
> > select @InstKy, @MConKy, @Result
> That is kind of what I was expecting. The API Docs say that Execute returns
> false if the execute is an Update or if the Query returns does not return a
> result set. Not returning a results set is different than a query that returns
> an empty result set. Can you explain what this SP is trying to do ?
> I took a look at the 2.5.1 code and I see a subtile difference in how the
> Query is executed. In 2.5.1 we were using executeQuery and not execute.
> Can you try the following mod:
> Orig Code:
> m_Statement = conn.createStatement();
> if (! m_Statement.execute(m_QueryParser.getSQLQuery()))
> {
> throw new SQLException("Error in Query");
> }
> New Code:
> m_Statement = conn.createStatement();
> m_ResultSet = m_Statement.executeQuery(m_QueryParser.getSQLQuery()))
> return;
> Yes the change (executeQuery) works for all the situations I tested.
> Nearly all our stored procedures move data between a set of normalized tables
> of
> permanent data and another set of denormalized tables with temporary data. A
> whole bunch of overhead SQL is called as well, but no result sets are
> returned.
> Separate queries select the temporary data.
> Is the difference between execute and executeQuery going to break someone
> else's
> use?
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://nagoya.apache.org/jira/secure/Administrators.jspa
-
If you want more information on JIRA, or have a bug to report see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
