You're right, I didn't notice that the exception was coming from PreparedStatement.getBytest() later in my code, which I overlooked to adapt to recent changes in H2. Sorry for bothering you.
BTW Are BLOBs stored differently in H2 (as compared to VARBINARY)? Is there a performance difference between them? On Tuesday, September 1, 2020 at 4:44:15 AM UTC+2 Evgenij Ryazanov wrote: > PreparedStatement.setBytes() and PreparedStatement.setObject() with byte[] > argument pass a BINARY VARYING value to H2 (in some other drivers they may > pass a BINARY value, the JDBC specification allows such behavior too). It > obliviously can't be used for very long arrays. > > PreparedStatement.setBinaryStream() passes a BINARY LARGE OBJECT value to > H2 and accepts long streams. Did you really test it? I can't reproduce such > exception with this method, if you can, please, provide a complete test > case without third-party dependencies. > JDBC also has a Blob interface (Connection.createBlob()) with > Blob.setBytes() method where you can pass longer array too. > > JDBC specification doesn't specify any adjustments for behavior of its > methods depending on the type of assigned column. JDBC provides only > possibility to retrieve the expected type of parameter from an application, > but it isn't always known, because prepared statement or callable statement > may use parameters inside expressions where different types of values are > supported. Application must choose the proper method to pass a value by > itself. If data type of a passed value doesn't exactly match with type of > assigned column, DBMS perform an usual implicit cast. > -- You received this message because you are subscribed to the Google Groups "H2 Database" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/h2-database/971bdd08-6622-4dd7-aa97-b4b04720cb31n%40googlegroups.com.
