was curious about and
decided to give it a try on a test server. I guess we will just have to
wait for the next release.
On Friday, 16 June 2023 at 15:49:12 UTC+2 Andrei Tokar wrote:
> Hi Silvio,
> SQL dump / restore is the only supported way to transition from one
> version to the oth
Hello all,
I created a H2 test build from current trunk. Using this on a bunch of
databases created with 2.1.214 I get the following error on a rather large
part of them:
org.h2.mvstore.MVStoreException: File is corrupted - unable to recover a
valid set of chunks [2.2.219/6]
When reverting to
distinguish
the records for separate queries.
On Wednesday, 26 April 2023 at 11:12:19 UTC+2 Noel Grandin wrote:
>
>
> On 4/26/2023 11:03 AM, Silvio wrote:
> > We have some heavy queries that involve selecting records from a base
> cached table A (~100K records) that satisfy a
>
ad of a IN() when you
> have a list of FK_A from C:
>
> select *
> from a
> inner join c
> on a.pk = c.fk_a
>
> Why use (uncorrelated?) sub-queries?
>
> Best regards
> Andreas
>
> On Wed, 2023-04-26 at 02:03 -0700, Silvio wrote:
>
> We have some heavy qu
We have some heavy queries that involve selecting records from a base
cached table A (~100K records) that satisfy a quite a number of conditions
expressed as
A.PK [NOT] IN (...)
on a secondary cached table B (~10M) records. Although the subqueries use
indexed columns the overall query is very
upfront.
Cheers, Silvio
On Friday, 3 February 2023 at 16:06:11 UTC+1 Evgenij Ryazanov wrote:
> Hello!
>
> In the SQL Standard all character strings with universal character set (H2
> doesn't have any other character sets) are comparable with each other and
> all numbers are
I have a database table CUSTOMERS with a column CUSTOMER_CODE VARCHAR(20).
This column used to be filled with integral codes. Executing
SELECT COUNT(*) FROM CUSTOMERS WHERE CUSTOMER_CODE = 12345
always used to work fine on the table. Now for some reason a CUSTOMER_CODE
value 'C' has been insert
Hello Evgenij,
Thanks for the swift response. That is just the information I was looking
for. Thank you very much.
Kind regards,
Silvio
On Thursday, 26 January 2023 at 15:25:14 UTC+1 Evgenij Ryazanov wrote:
> Hello!
>
> NaN is not a literal, it's just an identifier.
>
>
DOUBLE typed values and is now no longer able to copy records from
one table to the other if the source value is a Nan.
Is there a way to do this or do we have to revert to using a parameter in
this case?
Cheers
Silvio
--
You received this message because you are subscribed to the Google Grou
Thanks Noel. String values are exactly what we where planning to keep as
parameters.
So in many cases one or more parameters will remain (for string values) but
most will be replaced by literals since in our case by far most column
types are numeric, timestamp or UUID.
I was hoping for perhaps
Apart from SQL-injection considerations Is there any advantage or
disadvantage in using PreparedStatement parameters versus literal values
when the statement will only be executed once?
Our generic database handling code currently uses statement parameters for
all situations and column types. W
Right! Thanks Evgenij, I will change that immediately.
Thanks again guys.
On Friday, 30 September 2022 at 12:57:50 UTC+2 Evgenij Ryazanov wrote:
> Hello!
>
> You need to pass true as the last argument (approximate). It allows to
> return a fast approximation instead of exact number of rows in t
BTW: there are usually about 30 tables. Some approaching 100K rows, the big
one being the only that goes into the millions.
On Friday, 30 September 2022 at 12:52:49 UTC+2 Silvio wrote:
> Thanks Noel,
>
> Also see my other remark. I will look into that table. Actually, we did
>
Thanks Noel,
Also see my other remark. I will look into that table. Actually, we did
some stuff directly on the INFORMATION_SCHEMA tables before but the H2
versions above 200 had some modified layout/content in there so we switched
to the JDBC call for this one.
On Friday, 30 September 2022 at
September 2022 at 12:40:06 UTC+2 Silvio wrote:
> I have a largisch database (~6G) which I use in H2 2.1.214 embedded mode
> on an NVME SSD. I use the JDBC call
>
> rsIdx = con.getMetaData.getIndexInfo(catalog,schema,table,false,false)
>
> to get the indexes for a single table (which is
million rows. The call takes about
14 seconds to return the index es/segments for the table. On a not-so-fast
older SSD the same call takes ~30 seconds.
Is there a reason that this takes so long? Is there a more efficient way to
determine which indexes are present on a table?
Thanks,
Silvio
That sounds clear enough. Since I can not guarantee my databases will not
be accessed from threads that may be interrupted (by the servlet container)
we have to use async. Thanks for clearing that up.
On Thursday, 28 July 2022 at 14:11:58 UTC+2 Evgenij Ryazanov wrote:
> Hello!
>
> file: and nio
And in addition to the above: are there any disadvantages in using async:
vs file: ?
On Thursday, 28 July 2022 at 13:01:47 UTC+2 Silvio wrote:
> This is listed as experimental but I read some posts where this was
> advertised as a way to prevent database corruption.
>
> What is
This is listed as experimental but I read some posts where this was
advertised as a way to prevent database corruption.
What is the risk in using this instead of file: in a production system?
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To u
Sorry for the late response, I was down with Covid.
That makes sense, thanks! I would have to look into user defined functions
but as long as they can make use of connection-specific state (the normal
CURRENT_TIMESTAMP would have to be used simultaneously on all connections
except the one perfo
CURRENT_TIMESTAMP on update?
I would like to change that value for each statement while redoing
application level database logging.
Kind regards,
Silvio
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop
I expected as much. Thanks.
On Monday, 18 July 2022 at 10:44:28 UTC+2 Noel Grandin wrote:
> On 2022/07/15 2:35 pm, Silvio wrote:
> >
> >
> > Can the recover tool be manipulated to open a database in some form of
> "safe mode"? Or is there any other way to read
Up until now we have been using H2-1.4.200 in production with multiple
thousands of (mostly smallish) databases. Every now and then we get
database corruptions. In all but one case, corrupted databases throw an
exception during opening of the database. Since the recover-tool seems to
open a dat
Hi all. Sorry for the noise. I just found the WHEN MATCHED and WHEN NOT
MATCHED clauses. These will solve my problem nicely. Thanks again.
On Friday, 8 July 2022 at 16:18:46 UTC+2 Silvio wrote:
> Hi all,
>
> This question may be a generic SQL one but since I am using H2 and some
Hi all,
This question may be a generic SQL one but since I am using H2 and some
special feature may be available I will try my luck here.
I am trying to perform a sequence of MERGE-statements as part of an attempt
to repopulate database tables from some form of custom database-logging.
The tab
Thank you for the info. I think I will resort to just dumping the database
structure and then writing all table contents in separate CSV files.
On Friday, 28 January 2022 at 03:06:19 UTC+1 Evgenij Ryazanov wrote:
> > did the same for the TIMESTAMP prefix
> You don't need that. H2 1.4.200 is able
I found the escape syntax in the SQL reference but I did not find anything
in the change log mentioning this behavior. Am I correct in assuming that
this was added after H2-1.4.200?
On Thursday, 27 January 2022 at 15:59:31 UTC+1 Silvio wrote:
> Well, that unfortunately does not solve the is
er. Trying
to import this with H2-1.4.200 fails.
But since I use
SCRIPT TO 'xxx' CHARSET 'UTF-8'
I would expect no such escaping to be present in the file. Is there
anything I can do to get rid of these escapes?
On Thursday, 20 January 2022 at 10:52:15 UTC+1 Silvio wrote
Thank you. I already expected that. I did not seek full backward
compatibility but since we use the database as a very plain table storage
without foreign keys, complex joins etc we can live with compatibility for
basic CREATE TABLE and INSERT statements only. So far we never had version
differ
Hello all,
Executing SCRIPT TO command from H2 2.1.210 generates an SQL file that can
not be processed by an application using 1.4.200. The culprit seems to be
that in INSERT statements UUID values are exported in their hex-string
format prefix by the UUID keyword. So it looks like
UUID 'x
Thanks. That is just what we need.
On Tuesday, 11 January 2022 at 14:19:29 UTC+1 Evgenij Ryazanov wrote:
> On Tuesday, 11 January 2022 at 20:37:40 UTC+8 Silvio wrote:
>
>> Can you elaborate on that? As I described in another recent post we plan
>> to use at least two H2 ver
Can you elaborate on that? As I described in another recent post we plan to
use at least two H2 versions (1.4.200 for legacy databases and 2.0.20x for
all new ones) from the same application by using 2.0.20x in the application
itself (embedded mode) and spawn a separate H2 TCP-server process tha
database with 199 or 200.
Silvio
On Monday, 3 January 2022 at 11:07:22 UTC+1 kanchan@gmail.com wrote:
> Hi,
>
>
>
> We are using Atlassian bamboo tool for build management and using embedded
> database.
>
> We are getting below error while running the bamboo, looks
layout or something
like that.
Thanks for any feedback.
Kind regards,
Silvio
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-databas
Hello all,
We use H2 (1.4.200) extensively in production environments. Our backup
mechanism consists of:
- stopping the process
- backing up a directory tree including hundreds/thousands of H2 databases
- starting the process
Bringing the process down is because of the fact that the H2 database
actively use any of the other currently
supported systems (PostgreSQL, SQLServer, MySQL) any more. I never bothered
to include Oracle. I used that quite heavily in the 8.x/9.x days and that
was enough for me to never touch it again.
Thanks again for sharing your thoughts. I will certainly look
is
a lot slower than H2 in my experience.
Cheers,
Silvio
On Tuesday, 23 February 2021 at 14:33:02 UTC+1 wuu...@gmail.com wrote:
> Don't hesitate to use H2 not only for < 100k records. It can handle far
> more. But upgrade may produce issues, so be careful.
>
> wtorek, 23 lu
We use H2 in production heavily and would love to upgrade but as long as
there is no actual version released we can only use 2.0.x for testing
purposes. If only we could get some ball park estimate about when 2.0.201
will be released with some highlights of improvements we can expect and
prefer
Hi Andrei,
I am more than happy with H2 not having a set release schedule. But having
no schedule or even rule of thumb at all is the other extreme.
For us users it would be great if any commitment was expressed to try and
make meaningful improvements available by releasing a new version, say,
I am running into issues with database files that are created with file
paths based on user input. One example has a path with a directory in it
that has a ; in it's name. Connecting to the database fails for obvious
reasons. Is there a way to encode such paths to prevent issues like this?
--
That was what I was thinking also. I was just wondering if there are some
usual suspects that might help me predict if and when this could arise. In
the past I read that LOBs where a problem area. They are used in this
database but only in a couple of places.
Another thing that might be of inf
One of our H2 databases (MVStore cached tables, h2-1.4.200, embedded mode,
JDK13, dedicated Linux server with 8G RAM and 4 CPUs) is about 1.8G in
size. The database is both queried and updated quite frequently by many
application users at the same time. The database does grow but at a very
slow
Thanks for confirming that. Internally our application uses java.time
almost exclusively but is converted where 3rd party APIs require so. The
JDBC binding for timestamp is currently one of these cases.
On Tuesday, 21 January 2020 14:46:43 UTC+1, Evgenij Ryazanov wrote:
>
> Hello.
>
> No, they
H2 supports preparedStatement.setObject(n,localDateTimeValue) and
resultSet.getObject(n,LocalDateTime.class). I would like to know if there
is any performance advantage to be gained by using this (i.e. H2 using
java.time internally instead of Date/Calendar) or is it a simple wrapper
around the
197...
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To view this discussion on the web visit
https://groups.google.c
107 is on the download page. That one should work also. I still have 196 from
before. Perhaps the H2 guys can help you with that.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, s
Try to run the Recover tool from H2 version 196 or 197. I regularly deal
with corrupted databases since moving to 199 and in 9 out of 10 cases the
older Recover tool works where the one in 199 will not. This does not only
hold for the Recover tool since 196/197 usually open my "corrupted"
datab
I have been closely monitoring H2 databases being used on my servers that,
as I described earlier, each maintain tens to a couple hundred concurrent
connections to up to a couple thousand H2 databases. Some of these now run
on h2-1.4.196.jar while most use h2-1.4.199.jar. I already reported many
Thanks Evgenij, that also makes sense. The database was indeed created
using an older version of H2.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+
Thanks Evgenij,
That sounds plausible. It is just that I would have expected the Recover
tool to be updated as well. Now the Recovery tool in 199 generates SQL that
199 can not process. A minor detail but that threw me off a bit.
Fortunately I was able to recover the database so little harm was
I have another database corruption case. But this time it is on a PageStore
DB and the exception contained a different message:
Row not found when trying to delete from index ".I18: ( /* key:9812 */
'ea5d1a40-2af9-4d88-8694-bac2c989f28d',
'83e2f118-2201-475d-9746-a60a97155cb7', 4, 4,
'490c
It is getting monotonic but we had another database corruption. It happened
on the same database I have been doing these tests on but since this is one
of the bigger databases we have that may not be remarkable.
Today we used a different recovery approach: instead of restoring a backup
(which la
Hi Andrei,
Did you get anywhere from here using my feedback? Or do you need more
information? I would be very interested to hear more about this problem.
We just had a very peculiar database corruption: the corrupted database
(~5Mb) can be accessed from 199 but it appears to be as good as empty
Hi Andrei,
Thank you again for delving into this. I built from master branch and first
ran the recover tool. You are definitely on to something here because where
199 trips over the database with an exception during the generation of
database.mv.txt master generates a similarly sized database.m
I managed to build h2 with openjdk8. The recover tool fails in the same way
with that version as it does with current 199. I tried with 198 and that
fails also. Then I tried 197 and that succeeds, just like 196.
--
You received this message because you are subscribed to the Google Groups "H2
D
I just tried to build but I am running openjdk13 (openjdk12 on the servers)
and the build fails (package com.sun.javadoc does not exist). I used to be
able to build H2 earlier when I was running openjdk11.
I will try building with an older JDK tomorrow. Any preference for one?
--
You received
Unfortunately not. The data belongs to a customer. I would be happy to do
any kind of testing for you though.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-
For what it's worth: using 196 directly on the original corrupted database
(so not to run the recovery tool but with our application) shows no signs
of the database being corrupted. I know this does not mean anything but
nothing I have tried showed any sign of errors or malfunction. Consider me
My first inspection of the recovered database reveals that the database
seems to be fully intact. I compared it with a backup from the day before
the corruption happened. The exact same set of tables is there and the
record counts in corresponding tables is the same or the differences are
small
Today I discovered something very interesting. I took a corrupted database
that 199 tripped over and tried running the recovery tool. This resulted in
a similar exception our application logged at the time the database got
corrupted:
jambo@jambo8:~$ java -cp h2-1.4.199.jar org.h2.tools.Recover
Thanks. I will take that into account.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send email
Yesterday evening at about 20:00 another database on one of our servers got
corrupted (at least that is when errors started appearing in the logging).
There was limited server load at the time. In this case it was a database
of about 850Mb.
To determine our options I would like to raise my earl
Thank you, that is an excellent suggestion. The times are very short now
but there is no pressing reason for that other than hoping it would reduce
resource consumption. I will change that ASAP.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
T
Additionally, large write queues are very common in our system. At least
one of the most recent corruptions occurred when a user performed an action
that caused a new table to be created and ~200K records to be inserted into
it (using separate connect/insert/disconnect cycles, pooled of course).
The database URLs currently look like:
jdbc:h2:/path/to/file;IGNORECASE=TRUE;MVCC=TRUE;LOCK_TIMEOUT=1
I have experimented with different FILE_LOCK settings but since the
databases are accessed from one single process this is unlikely to have any
influence. I could probably do without MVCC=T
Sorry for spamming but I am just thinking out loud here:
Suppose we do leak connections across threads and multiple writes and/or
closes are performed on the same connections. Could that cause database
corruption? I know it is a hard call but does it sound likely or even
possible that changes s
Unfortunately we currently have another case of database corruption. The
exception stack trace is identical to the one I posted above. What strikes
me is that the messages reads "database: flush" and subsequently the stack
trace seems to imply the database is being opened. That sounds
contradic
Yes, databases are shutdown and reopened constantly since the connection
pool will only keep unused connections around for a short period of time
before closing them. As a result databases are closed by H2 automatically
once the last connection is closed. This particular type of issue appears
t
Today we experienced another database corruption. The difference with
earlier cases is that this time it happened during normal production use of
the system while the previous cases seemed to occur during nightly system
restarts.
The system is a Ubuntu 19.04 server running a singular standalone
Thank you for the response Evgenij,
On Thursday, 25 April 2019 15:46:30 UTC+2, Evgenij Ryazanov wrote:
>
> Hello. No, you can't copy a database file if database was not closed
> properly, but you can use a SHUTDOWN command to close it.
>
Ok, so that means that closing all connections is not enou
Hello all,
Since our upgrade to h2-1.4.199 we are experiencing frequent database
corruptions. I reported this earlier and have seen at least one similar
report from someone else in this group showing an almost identical error.
There has been no response since.
Is there any reason to assume 1.9
Hmm, sorry for the confusion. This was a result of sloppy log copying.
This is what happens now:
2019-04-12 09:24:17 database: flush
org.h2.message.DbException: General error:
"java.lang.IllegalStateException: Reading from nio:/path/to/database.mv.db
failed; file length 488419328 read length 40
Hello all,
We have experienced repeated database corruption issues after upgrading
from 1.4.196 tot 1.4.199. The scenario is always the same:
- the application uses an embedded file-based database (MVStore, close to
500Mb)
- the application is stopped (kill on linux, normal shutdown, no kill -9
Thank you Evgenij, that clears up things a lot.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group,
In several threads the connection option LAZY_QUERY_EXECUTION=1 has been
mentioned, mostly as an option to improve performance with large result
sets.
I have been looking into the documentation but can not find any more
information about this option. I do understand what the option is about
gl
string and let H2 figure out the type of
database but using distinct connection strings would be feasible.
Silvio
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an e
Ok, I was merely doing this because an export of a database in normal mode
often results in considerable growth of the database file. One use case is
converting the database from PageStore to MVStore and then this is fine.
But the same code is used for exporting production units to test
environ
Well, I did manage to get this working. I was using ACCESS_MODE_DATA=r to
open the database in read-only mode thinking that would sooner help than
hurt. Turns out the opposite is true. I removed this from the connection
string and it worked.
Additionally, I did the same test on the successfully
I just tried MAX_MEMORY_ROWS=1000, same result.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, s
I just ran my old code against the latest sources from Git. Sorry to say
that the result is identical: the process throws an OOM exception.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails
Thank you for pointing add the compression and encryption options, it eases
the pain a bit.
I understand that an OutputStream could not be used with an SQL command but
was referring to some internal code I could call directly with an
OutputStream since I am talking about embedded mode. The "SC
Well, that does work. It has the disadvantage of writing unencrypted data
to the file system and it temporarily takes up quite some space (I was
streaming the data via a ZipOutputStream over HTTP to a different server).
It would be great if there was some way to call the same process with an
Ou
Hello Noel,
Thanks for the suggestion. Using the command line is a no-go for my
server-application but writing to a temp-file could work. I will give that
a go.
Kind regards,
Silvio
--
You received this message because you are subscribed to the Google Groups "H2
Database"
is code is converting old PageStore databases to MVStore ones.
Any ideas?
Kind regards,
Silvio
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to
Thank you for this. that will solve my problem with the next release. I
will just have to skip 197.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+u
I would like to add that most of the applications is working fine and the
databases can be accessed for the most part. Only specific application
functions (in this case removing records from a couple of tables) is
affected.
--
You received this message because you are subscribed to the Google
fic subset like affected column
types or so? Anything that makes a conversion batch more manageable?
Kind regards,
Silvio
On Wednesday, 22 August 2018 13:49:59 UTC+2, Evgenij Ryazanov wrote:
>
> For information:
>
> The only one reliable way to upgrade from 1.4.196 to a more recen
I added a stack trace from a similar failure. This is in a PageStore
database.
Relevant part of stack trace:
org.h2.jdbc.JdbcSQLException: General error: "java.lang.RuntimeException:
Unexpected code path" [5-197]
at org.h2.message.DbException.getJdbcSQLException(DbException.java:357)
at org
t since we like to keep up with new and
improved versions I would like to resolve this ASAP.
Kind regards,
Silvio
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it,
Thank you for the response Evgenij,
The databases are quite flat. No CLOB/BLOBs, foreign keys or anything fancy
etc. They do contain a couple of dozens of tables with up to a couple of
dozen columns. And some of the tables may contain up to 50K rows. In
PageStore and newly created MVStore terms
I made one additional observation which is quite puzzling.
The increase in database size happens asynchronously. At the moment the SQL
script has been written (and the connection that was used to issue the
"SCRIPT" command has been closed) the database is only partially inflated.
Some backgrou
Besides primay keys that would be zero.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group, send emai
I tried connecting to the database from the H2 query tool and executing
"script". Same thing happens there.
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-da
prevented?
Kind regards,
Silvio Bierman
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.com.
To post to this group,
On Thursday, 7 December 2017 15:13:40 UTC+1, Noel Grandin wrote:
>
>
> Of course. Under most conditions (ie. with setAutoCommit==true), the
> transaction is complete and closed before the
> ResultSet is even returned to the client.
> This is how JDBC works on most databases.
>
A read-only res
On Thursday, 7 December 2017 12:24:10 UTC+1, Noel Grandin wrote:
>
>
> That is doable, but has nasty performance surprises if you, for example,
> do SELECT * on a table with a LOB column. If
> the LOB is big enough, it gets buffered to disk on the client side, and
> your SELECT performance is s
On Thursday, 7 December 2017 10:33:36 UTC+1, Noel Grandin wrote:
>
>
> Backwards compatibility is important to us, and the H2 code has worked
> this way since I started working on it.
>
I totally agree backward compatibility is important. That is why I opted
for a (connection/database) setting
On Wednesday, 6 December 2017 20:27:52 UTC+1, Noel Grandin wrote:
>
> Well, there is also the matter of not having enough time - it would be
> fairly complex to get all the edge cases right.
>
>
I think we all understand that you have limited time and resources, no
argument there. I would just l
Plase make that a setting. Let's not all suffer for some scarse edge cases
--
You received this message because you are subscribed to the Google Groups "H2
Database" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to h2-database+unsubscr...@googlegroups.c
How do you retrieve the date/time? I mainly use timestamp and
store/retrieve them as a timestamp, which is a millisecond offset from the
epoch that holds no timezone info. Same value goes in and out, whatever the
current timezone is. But if you retrieve dates/times in string format you
force H2
1 - 100 of 143 matches
Mail list logo
