I tried connecting to the db using 10.2.2.0 with and without transaction
logs. No luck.
The client was not following recommended backup procedures, so there
isn't much in the way of backups. In fact, our application prompts the
user to backup their data every time they exit the app. There isn't
This derby.log is indeed a recovery boot error. It has the feel of
the kind of error one would get if someone had deleted a log file
from the log directory. I've also seen this kind of error if someone
copies an active derby database without using derby backup to insure
a consistent set of datab
Yes, I have the original database with transaction logs intact.
Attached is derby.log. The error is what happens when I try to connect
using the original database with no modifications. I'm using cloudscape
workbench to try to connect. Also, the version of Derby I'm using
10.2.1.6, not 10.1.x
NEVER, NEVER, NEVER, . delete transaction log files from a database
that you ever hope to get a consistent view of again. If you are really
getting a recovery error when trying to boot the database you may have
to resort to extreme measures if you have no backup to go to, but
anytime you del
thanks for your answer. But why is there already a lock on the row.
You can find extensive information about Derby's locking behavior here:
http://db.apache.org/derby/docs/10.2/devguide/cdevconcepts30291.html
thanks,
bryan
Kasper, Kay wrote:
thanks for your answer. But why is there already a lock on the row. All
outher statements have been committed or have not selected the row. So there
should be no other lock.
I suspect that the update statement has left the row locked. In general
you can't rely on a database
Kasper, Kay wrote:
Hi,
i have a problem with the locking of a row. the situation:
Derby (10.1.3.1 and 10.2.6.1) running as server with two separatly running
client-applications (ij and own application).
Within my application i create a row in the database and commit.
With ij i change the row (
Hi Mark,
thanks for your answer. But why is there already a lock on the row. All
outher statements have been committed or have not selected the row. So there
should be no other lock.
I use the standard row locking of Derby which is, as far as i know,
TRANSACTION_READ_COMMITTED.
Kay
-Ursprün
Hi,
I have a client's database that I cannot connect to. I assumed that it
was a result of a transaction log corruption or some such thing since we
have seen that in the past. As an attempt to salvage it, I tried
deleting the two transaction logs in the log folder. Now, I can open
it, but when
Kasper, Kay wrote:
On other databases like Orcale and hqsl i don't have that problem. Whats
wrong with the row locking? Why does a normal select try to set a lock?
Unless your transaction isolation is TRANSACTION_READ_UNCOMMITTED, I
think a row (or table) lock is required for any select.
Ma
I should note that we are using derby 10.1.6.
-Original Message-
From: BALDWIN, ALAN J [AG-Contractor/1000]
Sent: Thursday, June 07, 2007 9:43 AM
To: 'Derby Discussion'
Subject: java.sql.SQLException: An inter
Hi,
i have a problem with the locking of a row. the situation:
Derby (10.1.3.1 and 10.2.6.1) running as server with two separatly running
client-applications (ij and own application).
Within my application i create a row in the database and commit.
With ij i change the row (only the one column f
Kasper, Kay wrote:
Hi,
i try to use a select-statement like this
"(select col1, col2, null, col4 from tablex)"
in an insert-statement.
As a result i get an SQLException with state 42X01, code 3 that says
syntax error at null.
Even if i use a very simple statement like (i created a table
Hi,
i try to use a select-statement like this
"(select col1, col2, null, col4 from tablex)"
in an insert-statement.
As a result i get an SQLException with state 42X01, code 3 that says
syntax error at null.
Even if i use a very simple statement like (i created a table like DUAL in
Oracle)
chihiro wrote:
Hi,
I'm programmatically starting my Network servers & I just want to say:
having to pass configuration info via System properties is not good design.
I'm trying to redirect the output that's going to derby.log to different
files & having to define derby.stream.error.method before
15 matches
Mail list logo