When trying to establish a connection to an HSQL database, I am getting this error message:
error in script file line: 1 /Users/jesse/Downloads/SyncData2_MirrorSync/mirrorsync invalid property name
Looking at the .script file, it looks like everything has been reset to empty / default values.
This happened after the machine ran out of memory and threw a OutOfMemory: Java heap space error (not during an HSQL-related operation, although the program would have attempted to SHUTDOWN after the OutOfMemory error was thrown).
1) Is there any way to recover the .script file so that I can open the database? The rest of the files (ie. the .data file) look OK when I look at the binary data. The .properties file does contain modified=yes, the .backup file exists but I don't know how to read it, and the .log file is almost empty. Would it be helpful to get a backup copy of the .script file from a few days ago, even if it didn't match the contents of the current .data file?
2) Is this expected behavior if the JVM runs out of memory? Is there anything I can do (short of doubling the memory allocation and hoping that's enough) to prevent this in the future?
.script contents:
SET DATABASE UNIQUE NAME null
SET DATABASE GC 0
SET DATABASE DEFAULT RESULT MEMORY ROWS 0
SET DATABASE EVENT LOG LEVEL 0
SET DATABASE TRANSACTION CONTROL MVCC
SET DATABASE DEFAULT ISOLATION LEVEL READ COMMITTED
SET DATABASE TRANSACTION ROLLBACK ON CONFLICT TRUE
SET DATABASE TEXT TABLE DEFAULTS ''
SET DATABASE SQL NAMES FALSE
SET DATABASE SQL REFERENCES FALSE
SET DATABASE SQL SIZE TRUE
SET DATABASE SQL TYPES FALSE
SET DATABASE SQL TDC DELETE TRUE
SET DATABASE SQL TDC UPDATE TRUE
SET DATABASE SQL TRANSLATE TTI TYPES TRUE
SET DATABASE SQL CONCAT NULLS TRUE
SET DATABASE SQL UNIQUE NULLS TRUE
SET DATABASE SQL CONVERT TRUNCATE TRUE
SET DATABASE SQL AVG SCALE 0
SET DATABASE SQL DOUBLE NAN TRUE
SET FILES WRITE DELAY 0
SET FILES BACKUP INCREMENT FALSE
SET FILES CACHE SIZE 0
SET FILES CACHE ROWS 0
SET FILES SCALE 0
SET FILES LOB SCALE 32
SET FILES DEFRAG 0
SET FILES NIO FALSE
SET FILES NIO SIZE 256
SET FILES LOG TRUE
SET FILES LOG SIZE 0
ALTER SEQUENCE SYSTEM_LOBS.LOB_ID RESTART WITH 1
SET DATABASE DEFAULT INITIAL SCHEMA INFORMATION_SCHEMA
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.SQL_IDENTIFIER TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.YES_OR_NO TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.TIME_STAMP TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.CARDINAL_NUMBER TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.CHARACTER_DATA TO PUBLIC
.log contents:
/C1/SET SCHEMA SYSTEM_LOBS
INSERT INTO BLOCKS VALUES(0,2147483647,0)
COMMIT
.properties contents:
HSQL Database Engine 2.3.3
Mon Jun 01 09:18:24 PDT 2015
version=2.3.3
modified=yes
tx_timestamp=7
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
This is not expected behavior in any known scenario.
If you use an older .script file with a newer .data file, it will probably throw an exception. If you have not updated or delete rows since the old .script file, chances are better. If it does connect, you must perform SHUTDOWN SCRIPT. If your application needs improved recovery methods in cases like this, you can switch to HyperXtremeSQL which should be able to recover from something like this if there is an older backup.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
When trying to establish a connection to an HSQL database, I am getting this error message:
error in script file line: 1 /Users/jesse/Downloads/SyncData2_MirrorSync/mirrorsync invalid property name
Looking at the .script file, it looks like everything has been reset to empty / default values.
This happened after the machine ran out of memory and threw a OutOfMemory: Java heap space error (not during an HSQL-related operation, although the program would have attempted to SHUTDOWN after the OutOfMemory error was thrown).
1) Is there any way to recover the .script file so that I can open the database? The rest of the files (ie. the .data file) look OK when I look at the binary data. The .properties file does contain modified=yes, the .backup file exists but I don't know how to read it, and the .log file is almost empty. Would it be helpful to get a backup copy of the .script file from a few days ago, even if it didn't match the contents of the current .data file?
2) Is this expected behavior if the JVM runs out of memory? Is there anything I can do (short of doubling the memory allocation and hoping that's enough) to prevent this in the future?
.script contents:
SET DATABASE UNIQUE NAME null
SET DATABASE GC 0
SET DATABASE DEFAULT RESULT MEMORY ROWS 0
SET DATABASE EVENT LOG LEVEL 0
SET DATABASE TRANSACTION CONTROL MVCC
SET DATABASE DEFAULT ISOLATION LEVEL READ COMMITTED
SET DATABASE TRANSACTION ROLLBACK ON CONFLICT TRUE
SET DATABASE TEXT TABLE DEFAULTS ''
SET DATABASE SQL NAMES FALSE
SET DATABASE SQL REFERENCES FALSE
SET DATABASE SQL SIZE TRUE
SET DATABASE SQL TYPES FALSE
SET DATABASE SQL TDC DELETE TRUE
SET DATABASE SQL TDC UPDATE TRUE
SET DATABASE SQL TRANSLATE TTI TYPES TRUE
SET DATABASE SQL CONCAT NULLS TRUE
SET DATABASE SQL UNIQUE NULLS TRUE
SET DATABASE SQL CONVERT TRUNCATE TRUE
SET DATABASE SQL AVG SCALE 0
SET DATABASE SQL DOUBLE NAN TRUE
SET FILES WRITE DELAY 0
SET FILES BACKUP INCREMENT FALSE
SET FILES CACHE SIZE 0
SET FILES CACHE ROWS 0
SET FILES SCALE 0
SET FILES LOB SCALE 32
SET FILES DEFRAG 0
SET FILES NIO FALSE
SET FILES NIO SIZE 256
SET FILES LOG TRUE
SET FILES LOG SIZE 0
ALTER SEQUENCE SYSTEM_LOBS.LOB_ID RESTART WITH 1
SET DATABASE DEFAULT INITIAL SCHEMA INFORMATION_SCHEMA
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.SQL_IDENTIFIER TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.YES_OR_NO TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.TIME_STAMP TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.CARDINAL_NUMBER TO PUBLIC
GRANT USAGE ON DOMAIN INFORMATION_SCHEMA.CHARACTER_DATA TO PUBLIC
.log contents:
/C1/SET SCHEMA SYSTEM_LOBS
INSERT INTO BLOCKS VALUES(0,2147483647,0)
COMMIT
.properties contents:
HSQL Database Engine 2.3.3
Mon Jun 01 09:18:24 PDT 2015
version=2.3.3
modified=yes
tx_timestamp=7
This is not expected behavior in any known scenario.
If you use an older .script file with a newer .data file, it will probably throw an exception. If you have not updated or delete rows since the old .script file, chances are better. If it does connect, you must perform SHUTDOWN SCRIPT. If your application needs improved recovery methods in cases like this, you can switch to HyperXtremeSQL which should be able to recover from something like this if there is an older backup.