db-derby-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Jack Klebanoff <klebanoff-de...@sbcglobal.net>
Subject Re: [jira] Commented: (DERBY-156) Delete with alias on column fails
Date Fri, 08 Apr 2005 22:09:27 GMT
Kathey Marsden wrote:

>Shreyas Kaushik wrote:
>>Hi Kathey,
>>Thanks for all the guidance and help. Yes got one of my implicit
>>questions right :-) of how to debug the tests in the framework.
>>I would definitely do a wrie up for this and put it up on the web when
>>I am comfortable doing this.
>>Yes this sort of information would definitely hep users debug the
>>tests in the framework.
>>Evan after running the tests with the properties that you had
>>mentioned the tmp file did not have any major changes ( no stack
>>tarces for the error I got ),
>>except for a few warning message relating to empty tables.
>>One interesting I noticed is that the select statement in the test
>>that is prior to this is, does a  similar operation and the result
>>fetches two rows.
>>So I presume the delte should delete two rows am I missing something
>>obvious here ?
>>I did a pass of code that I have changed, I just pull the correlation
>>name from the query and pass it to the DeleteNode. Could this be a
>>binding problem?
>>Looks like that from the error I am getting. I will look at this
>>aspect more, any more pointers/comments on my code changes will
>>definitely help.
>>~ Shreyas
>>Kathey Marsden wrote:
>Hi Shreyas,
>I am glad you are back on the trail with this issue and have some
>ideas.    I really can't answer your specific question at all because I
>don't know *what* SQL we are talking about here,  but if after some more
>research, you are still  stuck,  feel free to post a question.  Don't
>forget to include the five key ingredients to getting answers from busy
>people on the list.
>1) The small bit of sql or java code in question.
>2) A description of the old and new behaviour and what you think the
>right behavior should be.
>3) The stack trace if there is one.
>4) What you have learned so far from your own evaluation of 1-3 above.
>5) A specific question that is not going to take a lot of research for
>someone to answer that you think might send you back along your way if
>For this post I think you would have done a pretty good job with 4 and 5
>if  1, 2, and 3 were here too.
> I think you forgot 1 and 2. below are some tips for step 3 to get a
>stack trace.
>          a)  Create a small repro.sql script
>                Take just enough sql to get the specific sql from step 1
>                 (Usually some ddl some inserts and then the trouble maker)
>          b)    start ij with  -Dij.exceptionTrace=true and execute the sql.
>Here is an example.    Looks like I need help with my select statement #:)
>$ java -Dij.exceptionTrace=true org.apache.derby.tools.ij
>ij version 10.1
>ij> run 'repro.sql';
>ij> connect 'jdbc:derby:wombat;create=true';
>ij> create table mytab(i int);
>0 rows inserted/updated/deleted
>ij> insert into mytab values(1);
>1 row inserted/updated/deleted
>ij> selectoops from mytab;
>ERROR 42X01: Syntax error: Encountered "selectoops" at line 1, column 1.
>ERROR 42X01: Syntax error: Encountered "selectoops" at line 1, column 1.
>        at
>        at
>        at
>        at
>        at
>        at
>        at
>        at org.apache.derby.impl.tools.ij.ij.executeImmediate(ij.java:299)
>        at
>        at org.apache.derby.impl.tools.ij.utilMain.go(utilMain.java:310)
>        at org.apache.derby.impl.tools.ij.Main.go(Main.java:209)
>        at org.apache.derby.impl.tools.ij.Main.mainCore(Main.java:175)
>        at org.apache.derby.impl.tools.ij.Main14.main(Main14.java:55)
>        at org.apache.derby.tools.ij.main(ij.java:60)
>As for reviewing your code so far, I am sorry, but I don't think I have
>time to do that right now. Just too busy,  but perhaps someone else from
>the community can.  I  have noticed others from your company on the
>list.  I  know that a lot of times when I need a review,  I ping someone
>that I work with and have pretty good results that way. 
Another good place to look for debugging information is the derb.log 
file. When a test is run using the Derby test harness this file is found 
one level down from the test output. If the test output is in file 
dir/test.out then the log file is in dir/test/derby.log. The derby.log 
file has a record of the SQLExceptions, the statement that caused them, 
and the stack traces. I often look in derby.log first, though if the 
test does a lot of negative testing derby.log may  be cluttered with a 
lot of expected SQLExceptions.

Jack Klebanoff

View raw message