John,
Yes, I'm set for now. Thanks. Is the difference between execute and executeQuery going to break someone else's use?
BTW, I've another mod to the Xalan.jar which you might want to know about, but not include. It turns out that early versions of our application allowed users to inadvertently enter "bad" characters (0x00,0x01,...) into certain fields in the database. For the most part they are at the end of strings and are otherwise invisible to users. However, From the database they can be selected into variables in Xalan and written to an XML file. XML files with "bad" characters cannot be opened by Xalan/Xerces! So I've hacked org.apache.xalan.xslt.Process to filter the "bad" characters on the way in.
Regards, Phil Friedman - Terralink Software - 1-207-772-6500 x101
John Gentilin wrote:
Phil,
Thank you for the remote debugging effort. My in box is a bit stacked up at the moment, can I assume that you can proceed with your modified copy. I noted the change and will make it official in a week or so. If you can, add the bug into Bugzilla, cc me, I will close it once the change is implemented.
Regards John G Phil Friedman wrote:
John, 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.
Regards, Phil Friedman - Terralink Software - 1-207-772-6500 x101
John Gentilin wrote:
Phil,
Good debugging...
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;
You probably need to run the build script then substitute the new JAR file with the one you are using now.
Regards John G
Phil Friedman wrote:
John,
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
BTW, I'm going home, be back Monday...
Regards, Phil Friedman
John Gentilin wrote:
Phil,
I think what we are looking for is fairly straight forward. We need to know if the
execute returns false in SQLDocument and if so why. We should be able to figure that
out with the query that is being executed which will be stored in QueryParser. If you
get stuck, let me know what the problem is. I will be in an out today but should be able to get back to you in short order.
-JG
Phil Friedman wrote:
Hi John,
I finally got eclipse set up and can reproduce the problem w/ 2.6.0 source. I'll be stepping through things, but I'm a Java tyro. If you have a few minutes you can reach me at 1-800-343-5143 x101. Or, I'll keep you posted.
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
--------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
