do!
Russ
On 3/23/23 14:54, Russell Bateman wrote:
In fact, experimentation seems to suggest that the breaking point is a
length of 32K+. Whether or not the length of the rest of the INSERT
INTO statement counts I do not know for certain, but the delta between
MsgContent and the rest is negligeab
In fact, experimentation seems to suggest that the breaking point is a
length of 32K+. Whether or not the length of the rest of the INSERT INTO
statement counts I do not know for certain, but the delta between
MsgContent and the rest is negligeable, so I don't care.
On 3/23/23 13:02, Ru
According to what I'm reading, a CLOB should easily hold more than the
128K I'm trying to put into it.
My table schema:
private static final StringTABLE_SCHEMA ="\n" +" MsgId BIGINT NOT NULL GENERATED ALWAYS AS IDENTITY,\n" +" MsgContent CLOB DEFAULT NULL,\n" +" MsgReceived TIMESTAMP NOT NULL W
3) What happens when you do a
Class.forName("org.apache.derby.jdbc.EmbeddedDriver")? What are the
chain of errors raised? For the record, this is the recommended JDBC
way to fault in a driver which was missed at autoloading time.
Autoloading occurs on the very first call to
Driv
...again, don't know what I changed.* I'm only depending on
/derby-10.15.2.0.jar/.
What I think is going on is an artifact of being side-by-side with
another JDBC driver implementation.
I was hoping to keep the original mocked test driver working alongside
the Derby implementation at least u
red by JPMS. The original embedded driver
now lives in the tools jar. The autoloading driver moved into another
package in the engine jar. It is now called
org.apache.derby.iapi.jdbc.AutoloadedDriver.
Hope this helps,
-Rick
On 7/7/20 6:00 PM, Russell Bateman wrote:
How do the myriad Derby d
How do the myriad Derby drivers work?
I am using Apache Derby in-memory with no daemon or outside dependencies
in support of being called from JUnit tests. This is working pretty
well, but what it's going to be doing underneath will eventually cause
me to walk the following road, I think.
I
eems to me that you're running test with java 8 ( 50 => 6, 51 =>
7, 52 => 8, ...).
But Derby requires java 9.
Bye,
Davide Grandi
On 26/06/2020 17:11, Russell Bateman wrote:
I get UnsupportedClassVersionErrorin each case. Here's what that
looks like:
testDire
ollowing classes,
which live, respectively, in derby.jar, derbyshared.jar, and
derbytools.jar:
org.apache.derby.impl.jdbc.EmbedConnection
org.apache.derby.shared.common.util.ArrayUtil
org.apache.derby.jdbc.BasicEmbeddedDataSource40
Thanks,
-Rick
On 6/25/20 4:20 PM, Russell Bateman wrote:
O
Oops. I spoke too soon. I still had my JUnit tests @Ignore'd. It doesn't
work yet. I still get "no suitable driver." I added derbytools too, but
that made no difference. Further thoughts?
On 6/25/20 5:01 PM, Russell Bateman wrote:
Thank you; that's very kind. It
Hope this helps,
-Rick
On 6/25/20 1:28 PM, Russell Bateman wrote:
I have very recent code that works in a JUnit test case.
@Test
public void test()
{
final String DATABASE = "jdbc:derby:memory:sampledb;create=true";
final String USERNAME = "sa";
I have very recent code that works in a JUnit test case.
@Test
public void test()
{
final String DATABASE = "jdbc:derby:memory:sampledb;create=true";
final String USERNAME = "sa";
final String PASSWORD = "sa";
final String CREATE_TABLE = "CREATE TABLE names ( oid
12 matches
Mail list logo
