It was my mistake in describing. we do use the BACKUP command and then
since it produces a zip file, we create a new zip file and copy inputStream
to another outputStream to create a new zip file (with some configs related
to the DB) and then give that zip file to the customers to use as their
Hi,
OK, now I'm not sure if you use the "backup" statement or not, because at
the beginning you wrote you don't ("We have a feature that backs up the H2
DB file and zips it via java. the DB is in use when we back it up (all it
does is copy the h2 file)").
If you use the "backup" statement, then t
Hi,
OK, now I'm not sure if you use the "backup" statement or not, because at
the beginning you wrote you don't ("We have a feature that backs up the H2
DB file and zips it via java. the DB is in use when we back it up (all it
does is copy the h2 file)").
If you use the "backup" statement, then t
Pretty sure he is using the backup command.
> Here's the code:
String sqlStatement = "BACKUP TO ?";
try (Connection connection = getConnection())
{
try (PreparedStatement preparedStatement =
connection.prep
Hi,
> to do a test after the backup and copy to make sure the database can be
opened.
Testing a backup is a good idea in any case (even for regular backup).
However, just opening the database will not detect some types of errors.
You would need to do a complete read (for example using "script").
Copying an active data file creates and inconsistent image. This is writes
by the data engine occur randomly throughout the file, while reading from
the file is done serially. Essently later writes nearer the beginning of
the file that the reading point of the copy operation are not reflected i
Testing the backup sounds like a good idea. thanks. Still not sure what
would cause a corrupt db because if it happens while its in use, then this
is not a solution but it's a start.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscri
I have an application that uses BACKUP to copy the database to tablets
for offline use. It fails and produces a corrupt database about once a
year. It probably does 3000 or so copies a year. But like you, I'm not
sure if it is in the backup code or the copy code and I can't reproduce
it in a te
Here's the code:
> String sqlStatement = "BACKUP TO ?";
>>> try (Connection connection = getConnection())
>>> {
>>> try (PreparedStatement preparedStatement =
>>> connection.prepareStatement(sqlStatement))
>>> {
>>> preparedStatement.setS
CREATE_BUILD | 173 (h2-1.3.173.jar)
Using a ConnectionPool. We are using the BACKUP nativeH2 Query command.
We're not using 'MULTI_THREADED' property either so everything
defaultCIPHER=AES;TRACE_LEVEL_SYSTEM_OUT=0;ALLOW_LITERALS=NUMBERS
On Tuesday, September 2, 2014 10:42:05 PM UTC-7, Thom
Hi,
If you copy the file while the database is open, then the backup can be
corrupt in some cases (it's not so easy to reproduce it). Online backup is
supported, but you have to use the "backup" SQL statement (see the
documentation for details).
In theory the corruption can have other reasons. Wi
It isn't safe to backup the file that way. You need to use the inbuilt
backup command if the database is in use.
http://h2database.com/html/grammar.html#backup
http://h2database.com/javadoc/org/h2/tools/Backup.html
On 3/09/2014 6:27 AM, Kam wrote:
I don't know what's causing it. We have a
I don't know what's causing it. We have a feature that backs up the H2 DB
file and zips it via java. the DB is in use when we back it up (all it does
is copy the h2 file) When we tried to use it, it's corrupted. This is the
stack trace when I try to open it
ZipOutputStream append = new ZipOutput
13 matches
Mail list logo
