[jira] [Updated] (DERBY-6886) Fix links to CI test results

2016-04-29 Thread Bryan Pendleton (JIRA) 

 [ 
https://issues.apache.org/jira/browse/DERBY-6886?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
 ]

Bryan Pendleton updated DERBY-6886:
---
Attachment: updateSite.diff
updateSource.diff

This patch removes the links to the IBM and Oracle test results,
since they are hard to reach from the Open Source community,
and replaces them by a link to the Apache Jenkins latest test results.

> Fix links to CI test results
> 
>
> Key: DERBY-6886
> URL: https://issues.apache.org/jira/browse/DERBY-6886
> Project: Derby
>  Issue Type: Bug
>  Components: Web Site
>Reporter: Bryan Pendleton
>Assignee: Bryan Pendleton
>Priority: Minor
> Attachments: updateSite.diff, updateSource.diff
>
>
> The information on https://db.apache.org/derby/derby_tests.html
> is out of date.
> The best current test results are the Apache Jenkins test runs at:
> https://builds.apache.org/job/Derby-trunk-suites.All/
> The derby_tests.html page should be updated to reflect that status.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

[jira] [Created] (DERBY-6886) Fix links to CI test results

2016-04-29 Thread Bryan Pendleton (JIRA) 
Bryan Pendleton created DERBY-6886:
--

 Summary: Fix links to CI test results
 Key: DERBY-6886
 URL: https://issues.apache.org/jira/browse/DERBY-6886
 Project: Derby
  Issue Type: Bug
  Components: Web Site
Reporter: Bryan Pendleton
Assignee: Bryan Pendleton
Priority: Minor


The information on https://db.apache.org/derby/derby_tests.html
is out of date.

The best current test results are the Apache Jenkins test runs at:

https://builds.apache.org/job/Derby-trunk-suites.All/

The derby_tests.html page should be updated to reflect that status.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)

Re: are there any historical test run results available any more for derby?

2016-04-29 Thread Bryan Pendleton 

I look at the following page to find derby test results:
https://db.apache.org/derby/derby_tests.html

Neither of the links worked today, both got 404 errors.


Here's the discussion about this we had about 6 months ago; I don't
think anything significant has changed since then.

http://mail-archives.apache.org/mod_mbox/db-derby-dev/201510.mbox/%3C561307C9.6070508%40gmail.com%3E



If they are no longer supported we should remove the main page pointers.


+1

But, rather than remove those pointers, perhaps we should try to
point them to the Jenkins runs that Myrna noted at builds.apache.org.

I'll try to find time to do that soon.

bryan

are there any historical test run results available any more for derby?

2016-04-29 Thread mike matrigali 

I look at the following page to find derby test results:
https://db.apache.org/derby/derby_tests.html

Neither of the links worked today, both got 404 errors.
If they are no longer supported we should remove the main page pointers.

 * Oracle Java DB Regression Test Results 
 
http://download.java.net/javadesktop/derby/

I wonder if the one below is because of the apache home directory move?

IBM Regression Test Results 

http://people.apache.org/~myrnavl/derby_test_results/ 



--
email:Mike Matrigali - mikema...@gmail.com
linkedin: https://www.linkedin.com/in/MikeMatrigali

Re: Is there any debug logging available when a database is being recovered

2016-04-29 Thread mike matrigali 

I dont have much help to offer, only some history.  I do not think there was 
ever any performance work done
in this area, so hopefully there is some low hanging fruit.  I have a fuzzy 
memory that restart recover undo was
really inefficient as there is not a good way to walk backward in the log per 
transaction.

First would be good to understand performance per phase.  redo, vs undo.  i 
would expect redo to run pretty fast
but everything is very i/o bound if there is a lot of log and lot of database 
pages being looked at.  The whole
thing is single threaded and probably does not use very much memory.  so a lot 
of your machine resources
are not being used.  making it parallel is likely hard as there are likely 
assumptions on it being single threaded
and thus it does not need locks/latches for concurrency (or at least it can set 
flags saying it is ok with double latching).

to understand the size of the recovery you were looking at, what was the total 
size of seg0 of your db and what was
the log directory size.   And for log size do you know if you keep more than is 
required for restart recovery.  It would
be if you have the setting that keeps all old logs so that you can recover from 
a backup at specific time and then apply
current set of logs.

Also if you get set up to run experiments an easy test would be to run test 
first with I/O configured as we need for
correctness - ie with system sync write enabled.  And then run it with system 
write sync disabled.  If this is a big
difference you know the I/O part of problem is sync write vs some other issue.  
We have optimized doing as few sync
writes as necessary in "normal" path - but maybe there are recovery paths that 
do not.

Derby was originally designed to fit very small dbs with very low xact load.  
so there are very likely some assumptions
that don't fit your problem set.

On 4/25/2016 6:41 AM, Bergquist, Brett wrote:

Thanks for the pointes Kristian.   I definitely will be in this code shortly.

The system appeared to not be CPU bound but rather I/O bound.   I need to get a 
test setup into a condition like at the customer first and then start doing 
some debugging and profiling to see where things are.

-Original Message-
From: Kristian Waagan [mailto:kristwaa.apa...@gmail.com]
Sent: Saturday, April 23, 2016 4:22 PM
To: derby-dev@db.apache.org
Subject: Re: Is there any debug logging available when a database is being 
recovered

Den 20.04.2016 16.46, skrev Bergquist, Brett:

It took longer (and never finished) to process the recovery logs file that it did to 
restore the database from the previous night from backup (that took 6 hours to 
"untar")   At about 14 hours, the recovery log files were not finished 
processing so we had to give up and restore from backup.   That seems quite an inordinate 
amount of time to process the recovery log files.Note that this was not an 
underpowered machine either.   It was an Oracle M5000 with 32 processors, 128G of memory, 
and Fibre Channel attached storage.

I would like to start looking at this, so if anyone has any ideas where to 
begin, shout them out.

Hi Brett,

>From what I can see, there is some logging available in debug builds using the 
LogTrace-flag. I have no recollection of using it, so I cannot say how useful the 
information you get from enabling it is.

To try it, get the debug build and specify "derby.debug.true=LogTrace".
Based on a quick scan of the code, without verifying anything, it looks like 
you should see when Derby switches to the next log file. There is also a log 
entry for the end of the redo phase.

Obtaining the stack trace at various point might also give some clues if you're 
willing to dive into the code :)

I expect this part of the code is singlethreaded, so I hope the machine can 
give you decent performance using a single logical CPU. Do you suspect CPU or 
IO to be a bottleneck?


Regards,
--
Kristian


-Original Message-
From: Bryan Pendleton [mailto:bpendleton.de...@gmail.com]
Sent: Wednesday, April 20, 2016 5:53 AM
To: derby-dev@db.apache.org
Subject: Re: Is there any debug logging available when a database is
being recovered


So what would be useful would be something like:

Performing database recovery
Starting analysis pass
215 transactions detected to be processed Starting redo pass 
anything that could give some feedback Starting undo pass
anything that could give some feedback


I'm afraid all I can add is: yes, I completely agree, that would be extremely 
useful.

bryan



Canoga Perkins
20600 Prairie Street
Chatsworth, CA 91311
(818) 718-6300

This e-mail and any attached document(s) is confidential and is intended only 
for the review of the party to whom it is addressed. If you have received this 
transmission in error, please notify the sender immediately and discard the 
original message and any attachment(s).



Canoga Perkins
20600 Prairie Street
Chatsworth, CA 91311
(818) 718-6300

This e-mail and any attached

[jira] [Commented] (DERBY-6884) SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE bytes of blob data

2016-04-29 Thread Bryan Pendleton (JIRA) 

[ 
https://issues.apache.org/jira/browse/DERBY-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264997#comment-15264997
 ] 

Bryan Pendleton commented on DERBY-6884:


Maybe something like:

  java org.apache.derbyTesting.functionTests.harness.RunSuite largeData

might work?


> SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE 
> bytes of blob data
> 
>
> Key: DERBY-6884
> URL: https://issues.apache.org/jira/browse/DERBY-6884
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Edward Howe
> Attachments: DerbyIssue.java, firstTryAtTest.diff, trivial.diff
>
>
> Using SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE to export a table containing a blob 
> column, SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE  will fail with a 
> NumberFormatException if the offset for a blob record is > Integer.MAX_VALUE. 
>  This is because ImportReadData.initExternalLobFile() is parsing the offset 
> as an Integer.
> The stack trace and a program to reproduce are below.
> java.lang.NumberFormatException: For input string: "2147483770"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:583) ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_45]
>   at 
> org.apache.derby.impl.load.ImportReadData.initExternalLobFile(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.load.ImportReadData.getBlobColumnFromExtFile(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.ImportAbstract.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.Import.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.iapi.types.SQLBlob.setValueFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   ... 36 common frames omitted
> ==
> package blob;
> import java.io.BufferedInputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.sql.*;
> public final class DerbyIssue {
> // derby url
> public static final String DBURL = "jdbc:derby:testdb;create=true";
> // any random binary file such as a large image or document
> public static final String BLOB_DATA_FILE = "...";
> public static final String EXPORT_TABLE_FILE = "table-data";
> public static final String EXPORT_BLOB_FILE = "blob-data";
> public static void main(String... args) throws Exception {
> final DerbyIssue test = new DerbyIssue();
> test.run();
> }
> public void run() throws Exception {
> 
> Class.forName("org.apache.derby.jdbc.ClientDriver").getConstructor().newInstance();
> try(final Connection con = DriverManager.getConnection(DBURL)) {
> try (final Statement stmt = con.createStatement()) {
> stmt.execute("CREATE TABLE TESTBLOB(id BIGINT, content 
> BLOB)");
> }
> System.out.printf("inserting test data%n");
> try (final

[jira] [Commented] (DERBY-6884) SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE bytes of blob data

2016-04-29 Thread Bryan Pendleton (JIRA) 

[ 
https://issues.apache.org/jira/browse/DERBY-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264991#comment-15264991
 ] 

Bryan Pendleton commented on DERBY-6884:


I think the test suite you might be referring to is the "largeDataTests"

Unfortunately, all the references I can find to those tests are > 5 years old,
and my memory of how to run the old "runall" tests is fading.

Still, I agree with you in principle; I'll do more research here.


> SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE 
> bytes of blob data
> 
>
> Key: DERBY-6884
> URL: https://issues.apache.org/jira/browse/DERBY-6884
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Edward Howe
> Attachments: DerbyIssue.java, firstTryAtTest.diff, trivial.diff
>
>
> Using SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE to export a table containing a blob 
> column, SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE  will fail with a 
> NumberFormatException if the offset for a blob record is > Integer.MAX_VALUE. 
>  This is because ImportReadData.initExternalLobFile() is parsing the offset 
> as an Integer.
> The stack trace and a program to reproduce are below.
> java.lang.NumberFormatException: For input string: "2147483770"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:583) ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_45]
>   at 
> org.apache.derby.impl.load.ImportReadData.initExternalLobFile(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.load.ImportReadData.getBlobColumnFromExtFile(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.ImportAbstract.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.Import.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.iapi.types.SQLBlob.setValueFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   ... 36 common frames omitted
> ==
> package blob;
> import java.io.BufferedInputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.sql.*;
> public final class DerbyIssue {
> // derby url
> public static final String DBURL = "jdbc:derby:testdb;create=true";
> // any random binary file such as a large image or document
> public static final String BLOB_DATA_FILE = "...";
> public static final String EXPORT_TABLE_FILE = "table-data";
> public static final String EXPORT_BLOB_FILE = "blob-data";
> public static void main(String... args) throws Exception {
> final DerbyIssue test = new DerbyIssue();
> test.run();
> }
> public void run() throws Exception {
> 
> Class.forName("org.apache.derby.jdbc.ClientDriver").getConstructor().newInstance();
> try(final Connection con = DriverManager.getConnection(DBURL)) {
> try (final Statement stmt = con.createStatement()) {
>

[jira] [Commented] (DERBY-6884) SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE bytes of blob data

2016-04-29 Thread Mike Matrigali (JIRA) 

[ 
https://issues.apache.org/jira/browse/DERBY-6884?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel=15264183#comment-15264183
 ] 

Mike Matrigali commented on DERBY-6884:
---

there use to be a test suite for tests like this - especially clob/blob 
testing.  Even if you make it run fast, not everyone/everywhere will have the 
disk space to run it.  The suite was meant to at least be run once per release 
and more often by some nightly testing framework if possible - not sure if 
anyone runs it any more.

> SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE can't import more than Integer.MAX_VALUE 
> bytes of blob data
> 
>
> Key: DERBY-6884
> URL: https://issues.apache.org/jira/browse/DERBY-6884
> Project: Derby
>  Issue Type: Bug
>  Components: SQL
>Affects Versions: 10.11.1.1
>Reporter: Edward Howe
> Attachments: DerbyIssue.java, firstTryAtTest.diff, trivial.diff
>
>
> Using SYSCS_EXPORT_TABLE_LOBS_TO_EXTFILE to export a table containing a blob 
> column, SYSCS_IMPORT_TABLE_LOBS_FROM_EXTFILE  will fail with a 
> NumberFormatException if the offset for a blob record is > Integer.MAX_VALUE. 
>  This is because ImportReadData.initExternalLobFile() is parsing the offset 
> as an Integer.
> The stack trace and a program to reproduce are below.
> java.lang.NumberFormatException: For input string: "2147483770"
>   at 
> java.lang.NumberFormatException.forInputString(NumberFormatException.java:65) 
> ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:583) ~[na:1.8.0_45]
>   at java.lang.Integer.parseInt(Integer.java:615) ~[na:1.8.0_45]
>   at 
> org.apache.derby.impl.load.ImportReadData.initExternalLobFile(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.load.ImportReadData.getBlobColumnFromExtFile(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.ImportAbstract.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.load.Import.getBlob(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.iapi.types.SQLBlob.setValueFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.populateFromResultSet(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.VTIResultSet.getNextRowCore(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.ProjectRestrictResultSet.getNextRowCore(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NormalizeResultSet.getNextRowCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.NoPutResultSetImpl.getNextRowFromRowSource(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.HeapController.load(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.store.access.heap.Heap.load(Unknown Source) 
> ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.loadConglomerate(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.store.access.RAMTransaction.recreateAndLoadConglomerate(Unknown
>  Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.execute.InsertResultSet.bulkInsertCore(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.execute.InsertResultSet.open(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at 
> org.apache.derby.impl.sql.GenericPreparedStatement.executeStmt(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   at org.apache.derby.impl.sql.GenericPreparedStatement.execute(Unknown 
> Source) ~[derby-10.11.1.1.jar:na]
>   ... 36 common frames omitted
> ==
> package blob;
> import java.io.BufferedInputStream;
> import java.io.File;
> import java.io.FileInputStream;
> import java.io.IOException;
> import java.sql.*;
> public final class DerbyIssue {
> // derby url
> public static final String DBURL = "jdbc:derby:testdb;create=true";
> // any random binary file such as a large image or document
> public static final String BLOB_DATA_FILE = "...";
> public static final String EXPORT_TABLE_FILE = "table-data";
> public static final String EXPORT_BLOB_FILE = "blob-data";
> public static void main(String... args) throws Exception {
> final DerbyIssue test = new DerbyIssue();
> test.run();
> }
> public void run() throws Exception {
> 
> Class.forName("org.apache.derby.jdbc.ClientDriver").getConstructor().newInstance();
> try(final Connection con = DriverManager.getConnection(DBURL)) {
> try (final Statement stmt =

Yvonne hat nach Dir gesucht!

2016-04-29 Thread derby-dev@db.apache.org 
Hallo d ,

Du wurdest von Yvonne als Freund hinzugefügt.

Möchtest Du die Anfrage bestätigen oder ablehnen?
http://www.klicken49.site/OMCmXU19nLhl/

Möchtest Du das Profil von Yvonne aufrufen?
http://www.klicken49.site/OMCmXU19nLhl/user/Yvonne/

Viele Grüße,
Deine Freundschaftszentrale








-- 
Keine weiteren Benachrichtigungen?
http://www.klicken49.site/abm/OMCmXU19nLhl/