On Mon, Mar 6, 2017 at 3:39 AM, Yuri wrote:
> On 03/06/2017 01:00, Dominique Devienne wrote:
>
>> This is clearly documented inhttps://www.sqlite.org/c3ref/blob_open.html
>> though, so I'm afraid this is "by design". --DD
>>
>
>
> Even though this is documented, parts of this
Yuri wrote:
> Updating an integer field in the same row shouldn't affect the blob field.
Integer fields have a variable size (0 to 8 bytes):
http://www.sqlite.org/fileformat2.html#record_format
Regards,
Clemens
___
sqlite-users mailing list
AFAICT It is not the new value of the integer but rather the new contents of
the blob field that causes the record image to grow and exceed the previously
allocated space, which means the row has to move. Rewriting the record and thus
expiring the blob handle is triggered by the update of the
On Mon, Mar 6, 2017 at 11:39 AM, Yuri wrote:
> On 03/06/2017 01:00, Dominique Devienne wrote:
>
>> This is clearly documented inhttps://www.sqlite.org/c3ref/blob_open.html
>> though, so I'm afraid this is "by design". --DD
>>
>
> Even though this is documented, parts of this
On 03/06/2017 01:00, Dominique Devienne wrote:
This is clearly documented inhttps://www.sqlite.org/c3ref/blob_open.html
though, so I'm afraid this is "by design". --DD
Even though this is documented, parts of this limitation don't appear to
be reasonable. Updating an integer field in the
On Sat, Mar 4, 2017 at 8:21 AM, Yuri wrote:
> The write operation using the open sqlite3_blob object fails after some
> other field in the same row is updated.
>
This is clearly documented in https://www.sqlite.org/c3ref/blob_open.html
though, so I'm afraid this is "by design".
The write operation using the open sqlite3_blob object fails after some
other field in the same row is updated.
The testcase below illustrates the problem.
Yuri
---testcase---
#include
#include
#include "sqlite3.h"
int main(int argc, char **argv) {
if(argc < 2) {
7 matches
Mail list logo