Ahh Well done JavaSoft!!!
----
.... the default transaction isolation level of the underlying database is used
for the result set that is created. Note that this code is
just JDBC 1.0 code, and that it produces the same type of result set that would
have been produced by JDBC 1.0.
Connection con = DriverManager.getConnection(
"jdbc:my_subprotocol:my_subname");
Statement stmt = con.createStatement();
ResultSet rs = stmt.executeQuery(
"SELECT emp_no, salary FROM employees");
The next example creates a scrollable result set that is updatable and sensitive
to updates. Rows of data are requested to be fetched
twenty-five at-a-time from the database.
Connection con = DriverManager.getConnection(
"jdbc:my_subprotocol:my_subname");
Statement stmt = con.createStatement(
ResultSet.TYPE_SCROLL_SENSITIVE,
ResultSet.CONCUR_UPDATABLE);
stmt.setFetchSize(25);
ResultSet rs = stmt.executeQuery(
"SELECT emp_no, salary FROM employees");
----
``setFetchSize( N )''
Surf to:
http://www.javasoft.com/products/jdk/1.2/docs/guide/jdbc/spec2/jdbc2.0.frame5.ht
ml
Over to all you JDBC implementors
Pete
______________________________ Reply Separator _________________________________
Subject: Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Wh
Author: Peter Pilgrim at London
Date: 13/11/98 18:00
Pass! I have no idea. But it is not really useful in a GUI.
[EXECUTE] SQL query [ABORT] SQL query
What timeout should I have set BEFOREHAND.
Should it be 1 ms , 1sec , and 1 hour
For a non-deterministic application like an event driven GUI.
I think not, I'm afraid.
For application threads which you and have source for now. It is better
to use a synchronised interval work scheduling as other people have graciously
suggested. And yes, I agree this is best way for native thread support. However
if the API does not support it, then you are truly buggered. Most SQL queries
will be short and hopefully JDBC 2.0 will improve the situation with some sort
row iterator. Get rows 1 to 100, then 101 to 200, 201 to 301 and so on. May be
even how many rows will I be returned from this query if database can tell you
(percentage driven JProgressBar taar daa!). but for now ...
[ABORT] -------------------------------> queryThread.stop()
Unfortunately my weekend begins here.
Pete
______________________________ Reply Separator _________________________________
Subject: Re: Deprecated `Thread.stop()' in forthcoming JDK 1.2. Wh
Author: paul ([EMAIL PROTECTED]) at lon-mime
Date: 13/11/98 17:29
[EMAIL PROTECTED] wrote:
...
> Class.forName( "org.blackdown.jdbc.AnyOldDriver" );
> Connection con = DriverManager.getConnection( url, username, password
);
> Statement stmt = con.createStatement( "select * from JDK_RELEASES" );
>
> stmt.executeQuery(); // One atomic call with no way to run to !!!
> I have a spawn threads to execute the above SQL query and then allowed to
> operator to kill the thread if the query was slow.
Can stmt.setQueryTimeout(someTimeout) help you? Your software could even
compute different timeouts depending on expected query complexity.
Pavel
