db-derby-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Steven Buschman <sbu...@buschman.org>
Subject Re: res.updateXXX
Date Tue, 30 Nov 2004 13:17:59 GMT
Shreyas,

Thanks for the info. I'm new to this - I searched Derby's project and 
couldn't find this as an open issue - am I missing something?  It there 
a timetable on it being done? Please excuse my ignorance - what's my 
alternative to using updateable results short of using "update table set 
xxx=yyy where zzz"?

Thanks.

Steve

Shreyas Kaushik wrote:

>Hi Steven,
>
>Answers for your questions are inline.
>
>thanks
>Shreyas
>
>Steven Buschman wrote:
>  
>
>>Hello,
>>
>>First let me apologize in advance if I'm not following protocol - this 
>>is the first time I've accessed an Apache project, so newbie I am.
>>
>>I downloaded the compiled 56458 release successfully. My intention was 
>>to port a MySQL client application to Derby, primarily because of the 
>>near zero admin issues with Derby. After a bit of grief (there are quite 
>>a few differences), I'm down to just one problem that I can't figure out 
>>worked w/MySQL 4.1 and fails with Derby:
>>
>>Statement  state =  
>>connection.createStatement(ResultSet.TYPE_SCROLL_INSENSITIVE, 
>>ResultSet.CONCUR_UPDATABLE);
>>ResultSet  res     = state.executeQuery("select * from xxx where ...");
>>
>>if (!res.next())
>>   throw new Exception(...); // I'm sure the select will succeed!
>>
>>res.updateString(...); // SQLException occurs !!!! SHOULD NOT HAPPEN!!!
>>res.updateInt(...);
>>res.updateRow();
>>res.close();
>>state.close();
>>    
>>
>
>This is becasue Derby as of now does not support updatable ResultSets.
>  
>
>>On a separate note - a few issues that I observed:
>>1. Using ij, INSERT into table values (..), (...), (...) generates a 
>>stack overflow if there are too many inserts. I wanted to import 12,000 
>>rows in Derby and it failed after a dozen rows or so. I was stuck doing 
>>12,000 separate inserts, which took close to 2 minutes on a very fast 
>>machine (10K WD drive with 1 GB ram and AMD 64 939).
>>
>>2. After doing a "select * from table" with 6000 rows and 47 columns, it 
>>took 10 seconds to load the table if I used res.getXXX("text") but only 
>>1.5 seconds if I used res.getXXX(integer value).
>>
>>3. Derby: var INT NOT NULL GENERATED ALWAYS AS IDENTITY vs. MySQL: var 
>>INT NOT NULL AUTO_INCREMENT
>>My problem is that Derby won't let me assign a value to var even if it's 
>>unique. The problem here is that if you're importing data from elsewhere 
>>and "var" is being used as a foreign key in another table, then it's a 
>>major pain to make sure everything is in sync.
>>
>>All in all Derby is fantastic - never have I been able to download and 
>>port (99%) in just 1 day. I see tremendous opportunities for it for 
>>small scale applications.
>>
>>Thanks.
>>
>>    
>>
>
>
>
>  
>

-- 
Steve Buschman
22 Blackburnian Rd.
Lincoln, MA  01773
781-259-0295


Mime
View raw message