[odb-users] Re: sqlite mismatch in result column count
MM
finjulhich at gmail.com
Mon Sep 14 08:43:26 EDT 2015
On 14 September 2015 at 10:56, MM <finjulhich at gmail.com> wrote:
> Hello,
>
> This assertion, from sqlite, gets triggered:
>
> statement.cxx:331: bool odb::sqlite::statement::bind_result(const
> odb::sqlite::bind*, size_t, bool): Assertion `col == col_count' failed.
>
> Looking at the source code, there are 3 variables that relate to column
> count:
>
> bool statement::
> bind_result (const bind* p, size_t count, bool truncated)
> {
> }
>
> 1. The 'count' argument of bind_result: looking at the core file, its
> value is 4
> 2. col_count: I couldn't find its value from the core file. Is it the
> expected number of columns that is deduced from the SQL query before it is
> executed?
> If so, that number is 4 also.
> 3. col, I suppose this is the actual number of columns that is
> returned after executing the SQL query. I traced the odb query, executed
> the SQL query I see traced out, it has 4 columns, and the result also
> includes 4 columns.
> 4. The query is the result of a call: db.query<F>();
> F is a struct, where the number of non transient fields overall is 4
> as well.
> F(2 virtual members) derives from B1(odb abstract, 1 member) which
> derives from B0(odb abstract, 1 member).
>
> I will try to printout the values of those variables in my locally
> modified libodb-sqlite to see what's going on.
>
> Rds,
>
> After some debugging, I find that the value of 'col' is 3, not 4.
The loop goes through i=0,1,2,3 as expected.
if (b.buffer == 0) { // Skip NULL entries.
}
This happens once, and that is why col is 3.
I printed b.type, and 3 times, it is 0, ie bind::integer
The 4rd column (the missing one) is of type std::string in the c++ class
(B1), and of type TEXT in the db.
B1 is pragma'd like this
#pragma db object(B1) abstract definition
I assume this means to indeed declare all of its members as non transient.
I'm gonna explicitly declare the member here with #pragma member and see if
there's a difference
Rds,
More information about the odb-users
mailing list