Hi Malte,

malte.kem...@de.equens.com writes:


> Hi Dag, The problem in my case is, that I don't have access to any
> AIX-Computer, and that is really a pity, because I cannot
> reconstruct the scenario on my own and watch it with my own eyes.
> That all happened on a production system and the provider denies
> trying it out again.  But attached you can find the SQL-script
> without being UTF8.  So that Problem should occur in the same way
> used on AIX (5.3) BTW: is there a way to be kind of independent of
> the input format?

I converted the script you enclosed to UTF-8 and ran it through ij
without any problems. 

I also tried to run it with the enclosed program, and it gave me no
errors when the inout file was encoded with UTF-8 (Comments had
non-ASCII German character), and it printed no errors on my
OpenSolaris system (I don't have access to AIX).

In any case, should you see this problem again, please feel free to
file a bug report(*), preferably with a repro and/or logs.

As for independence of the input format, since runScript requires that
you specify the encoding, you could do some encoding auto-detect logic
on the script, I guess..

(*) http://db.apache.org/derby/DerbyBugGuidelines.html

Hope this helps,
Dag


import org.apache.derby.tools.ij;
import java.sql.*;
import java.io.*;

public class Foo {

    public Foo() {};

    static public void main(String[] args)
            throws SQLException,
                   UnsupportedEncodingException,
                   FileNotFoundException,
                   ClassNotFoundException {
        Class.forName("org.apache.derby.jdbc.EmbeddedDriver");
        Connection c = 
DriverManager.getConnection("jdbc:derby:wombat;create=true");

        FileInputStream fs = new FileInputStream(args[0]);

        int errs = ij.runScript(c,
                                fs,
                                "UTF-8",
                                System.out,
                                "UTF-8");

        System.out.println("\n\nerrs=" + errs);
        c.close();
    }
}




>
> Malte
>
> -----Ursprüngliche Nachricht-----
> Von: dag.wan...@sun.com [mailto:dag.wan...@sun.com] 
> Gesendet: Freitag, 27. November 2009 01:19
> An: Derby Discussion
> Betreff: Re: AW: AW: OOM with millions of weakly-referenced Derby objects
>
> malte.kem...@de.equens.com writes:
>
>> Yes this is the API I am reffering to.  Well actually it says that,
>> but in my case it did not do it.  It needed a long time, several
>> minutes. Reason as it turned later out, after getting the output in
>> a file a lot of IOExcceptions. I never got those on windows nor on
>> Solaris. Thr original logic of the routine calling the runScript
>> Method was asking for the return code but either it never hit this
>> if statement and crashed somewhere within ij without giving the
>> Exception to the caller or ij gave something like 0 so the output
>> never was given to the logger.  So there is something phony with
>> ij.runScript using it with AIX 5.3 and a SQL-Script not coded UTF8
>> but declaring in the parameters as UTF8. Of course that is a fault
>> by my own, but it should tel me about it.
>
> I looked at the implementation for runScript in
> org.apache.derby.impl.tools.ij.utilMain#runScriptGuts and it does seem
> to catch exceptions, count them and return them. Are you able to
> provide a repro script showing that 0 or -1 is returned from runScript
> for the failing scenario? 
>
> Thanks,
> Dag
>
>>
>>
>>
>> -----Ursprüngliche Nachricht-----
>> Von: dag.wan...@sun.com [mailto:dag.wan...@sun.com] 
>> Gesendet: Freitag, 20. November 2009 19:54
>> An: Derby Discussion
>> Betreff: Re: AW: OOM with millions of weakly-referenced Derby objects
>>
>> malte.kem...@de.equens.com writes:
>>
>>> In other words I would count that situation as not nice behaviour of ij, 
>>> since the return code should have been given as I would suppose it looking 
>>> at the method signature.
>>
>> Is this the API signature you are referring to?
>>
>> http://db.apache.org/derby/docs/10.5/publishedapi/jdbc4/org/apache/derby/tools/ij.html#runScript(java.sql.Connection,%20java.io.InputStream,%20java.lang.String,%20java.io.OutputStream,%20java.lang.String)
>>
>> It says:
>>
>> Returns:h
>>     Number of SQLExceptions thrown during the execution, -1 if not
>>     known. 
>>
>> If so, are you seeing 0 or -1 returned here?
>>
>> Dag

Reply via email to