Outch. Missed the first part of Derby's statement. Ok.
Doesn't make sense though. His insert is a batch insert? Imagine if you had a table where you were inserting a record that was larger than 64KB. (Not including blobs) Are you saying that Derby would have failed prior to your fix? Within the limitations of Derby and (Java), Leslie's app design doesn't make sense to begin with. > -----Original Message----- > From: Daniel John Debrunner [mailto:[EMAIL PROTECTED] > Sent: Thursday, September 07, 2006 1:33 PM > To: Derby Discussion > Subject: Re: ClassFormatError while performing a SQL insert > > [EMAIL PROTECTED] wrote: > > > But his issue isn't with Derby. > > > > He'd have the same problem with any Java app and a JDBC connection. > > We know this because Leslie wrote that if he inserted just a subset of > his > > data, it would work. ;-) > > Nope, the error Leslie reported is for a class generated by Derby: > > Leslie's error: > > org.apache.derby.exe.ac08264012x010dx8870x7dfdx0000000be0501 to file > ac08264012x010dx8870x7dfdx0000000be0501.class. > >java.lang.ClassFormatError: Invalid method Code length 69936 in class > file > > org/apache/derby/exe/ac08264012x010dx8870x7dfdx0000000be0501 > > The problem is that with a large SQL INSERT statement with many rows, > all values as literals the generated class size is a factor of the > number of rows. Reducing the number of rows reduces the generated > method's size and hence it works, increasing the number of rows > increases the method's size beyond the 64k limit. Changes in 10.2 allow > the generated code to be split over many methods, working around the > per-method limit. > > If it was an issue due to his application class being too big, it would > have failed when he compiled it, not at run time. > > But hey what do I know, I just spent six months fixing the very issue > that Leslie is running into. :-) > > Dan.
