I have successfully detected the offending data. There where three records in a table containing just over 100K records. They all contained a timestamp with a time-part that was displayed as 23:59:59 by version 1.3. Trying to access any column outside the PK value triggered the exception when using 1.4.
I can't see the advantage of the assert in this case. It looks to me there must have been a bug in 1.3 somewhere that allowed the creation of these invalid timestamp values. Once they are there in the data adding strictness afterwards IMHO only adds insult to injury. I now have three bad records and can therefore not read the rest of the 100K ones. Alternating selects on all columns versus the PK only combined with limit clauses and PK ordering I was able to binary search for the PK values of the offending rows using 1.4. Deleting these rows using 1.3 solves the problem. After that 1.4 works as expected. Unfortunately this is only one isolated incident. We have a couple of hundred of similarly structured databases that are access by the same process. I hope the problem does not reoccur. I very strongly propose getting rid of the assert or at least adding a connection setting to disable it. We have waited eagerly for 1.4 to reach production status and having to revert to 1.3 because of this would be a real setback for us. -- 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 [email protected]. To post to this group, send email to [email protected]. Visit this group at https://groups.google.com/group/h2-database. For more options, visit https://groups.google.com/d/optout.
