You can open a bug report if you wish.
The space for temporary lobs is reclaimed at each checkpoint and is reused for
future lobs.
It is not possible to reduce the size of the lobs file. There is a procedure in
HyperXtremeSQL for this, but not in HSQLDB.
Fred
On Tue, Jul 18, 2017, at 16:05, Al
Hi Fred,
because of the following reasons we consider this as a bug:
- the upper copy of the clob is not removed afterwards and the already
occupied space is not reused
- it is not easily possible to reduce the size of the lobs-file
- this behavior is not documented
Therefore I will open a bug in
Ok, thank you. Is it possible to reduce the size of the file again?
> Am 13.07.2017 um 18:08 schrieb Fred Toussi via hsqldb-developers
> :
>
> This is normal. An uppercase copy of the CLOB is created. To avoid it,
> cast the CLOB to VARCHAR before converting to uppercase.
>
> Fred Toussi
>
>>
This is normal. An uppercase copy of the CLOB is created. To avoid it,
cast the CLOB to VARCHAR before converting to uppercase.
Fred Toussi
On Thu, Jul 13, 2017, at 10:52, Alexander Gerbig wrote:
> Hallo hsqldb developers,
>
> we use a hsqldb in our application an experience a strange behavior.
Hallo hsqldb developers,
we use a hsqldb in our application an experience a strange behavior. We have
some clob columns in different tables and when we execute an select with an
upper on the clob column in a where clause the lobs file increases in size. Is
it a very practice to make an upper on
