@@ -628,7 +628,7 @@ custom certificates are supported as well.
<br/><aname="uuid"></a>
<h2>Universally Unique Identifiers (UUID)</h2>
This database supports the UUIDs, and function to create new value using
This database supports UUIDs. Also upported is a function to create new UUIDs using
a cryptographically strong pseudo random number generator.
With random UUIDs, the chance of two having the same value can be calculated
using the probability theory. See also 'Birthday Paradox'.
...
...
@@ -695,6 +695,8 @@ INFORMATION_SCHEMA.SETTINGS
<tr><td>h2.objectCache</td><td>true</td><td>Cache commonly used objects (integers, strings)</td></tr>
<tr><td>h2.objectCacheSize</td><td>1024</td><td>Size of object cache</td></tr>
<tr><td>h2.objectCacheMaxPerElementSize</td><td>4096</td><td>Maximum size of an object in the cache</td></tr>
<tr><td>h2.clientTraceDirectory</td><td>trace.db/</td><td>Directory where the trace files of the JDBC client are stored (only for client / server)</td></tr>
<tr><td>h2.scriptDirectory</td><td></td><td>Relative or absolute directory where the script files are stored to or read from</td></tr>
// int todoWriteTestThatCallsSystemHaltExtendTestLob;
// READ_CLOB, READ_BLOB
//create table test(id int, data array)
//document array_get, array_length
// here is a difference in behavior between the 9-24-2006 H2.jar and the later jars.
// Or it simply could be I didn't see a feature change in the docs.
// In my code, this statement in 9-24 works:
// SELECT ID FROM EVE_ALARMS WHERE TIME_ESCALATE = true AND ACTIVE = true AND current_timestamp() > NEXT_TIME_ESCALATION
// in latest versions, the query returns zero rows.
// Most of my queries are preparedStatements that are prepared once at process startup.
// Things I have tested:
// 1. Run the query in the H2 console. SUCCESS
// 2. Generate a preparedStatement each time it is needed. SUCCESS
// 3. Generate a preparedStatement, save the statement to a instance variable for reuse. FAIL
// There are several queries that use current_timestamp, but I think the cache is saving the original time value, ie not recalculating. This may be because there are no parameters set in the statement. The other queries that use current_timestamp have parameters that must be set, which I thinking causes the time value to be recalculated.
// I will try and put together a simple test case this week. Unless this a configuration issue and I need to RTFM. :)
// options for java functions: readonly, deterministic
// append errors from all programs atomically to errors.txt (use nio file lock mechanism)
// ftp client
// task to download new version from another FTP server
// TestRandomSQL is too random; most statements fails
// extend the random join test that compared the result against PostgreSQL
// Donate a translation: I am looking for people who would help translating the H2 Console into other languages. Please tell me if you think you can help
// extend TestJoin
// Donate a translation: I am looking for people who would help translating the H2 Console into other languages. Please tell me if you think you can help
// long running test with the same database
// repeatable test with a very big database (making backups of the database files)
// check performance monitor Avg. Disk Write Queue Length, disk writes
// test case where the GCJ problem can be repeated
// OpenOffice docs:
// - Stop OpenOffice, including the autostart
// - Copy h2.jar into the directory <OpenOffice>\program\classes
// - Start OpenOffice Base
// - Connect to an existing database, select JDBC, [Next]
