Re: [sqlite] Question on the VdbeCursor structure changes
I was using it to get the rowid of a given cursor in a SQLite statement.
Given a table schema like CREATE TABLE foo (A,B)
And an arbitrary select such as SELECT * FROM foo
I was able to return the rowid as a hidden column for the statement. This
included statements with multiple cursors (as a result of multiple joins).
-Original Message-
From: sqlite-users-boun...@sqlite.org
[mailto:sqlite-users-boun...@sqlite.org] On Behalf Of D. Richard Hipp
Sent: Saturday, April 17, 2010 11:08 AM
To: General Discussion of SQLite Database
Subject: Re: [sqlite] Question on the VdbeCursor structure changes
On Apr 17, 2010, at 1:02 PM, Paul Shaffer wrote:
> Due to changes in VdbeCursor structure, this code for 3.6.16 won't
> compile
> anymore:
>
> else if(pC->pseudoTable)
> {
> *prowid = pC->iKey;
> }
>
Your application should not be messing with internal data structures
of SQLite, all of which are subject to change without notice (as you
have discovered.)
Perhaps if you explain to us what you are trying to accomplish we will
be better able to help you.
> and for 3.6.23 would have to be replaced by something like this:
>
> else if(pC->pseudoTableReg>0)
> {
> //*prowid =
> }
>
> My problem is that after about an hour of reverse engineering I can't
> figure out a way to get the row id with the new code. Any help
> appreciated.
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
D. Richard Hipp
d...@hwaci.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Question on the VdbeCursor structure changes
Yes, it's for System.Data.SQLite. I'm trying to build it with the latest
engine code. I've commented out that one else-if that won't compile and so
far no errors, but that's a really bad way to proceed. The SQLiteKeyReader
c# class is trying to get a row id for a cursor.
declspec(dllexport) int WINAPI sqlite3_cursor_rowid(sqlite3_stmt *pstmt,
int cursor, sqlite_int64 *prowid)
{
Vdbe *p = (Vdbe *)pstmt;
sqlite3 *db = (p == NULL) ? NULL : p->db;
int rc = 0;
VdbeCursor *pC;
int ret = 0;
sqlite3_mutex_enter(db->mutex);
while (1)
{
if (cursor < 0 || cursor >= p->nCursor)
{
ret = SQLITE_ERROR;
break;
}
if (p->apCsr[cursor] == NULL)
{
ret = SQLITE_ERROR;
break;
}
pC = p->apCsr[cursor];
ret = sqlite3VdbeCursorMoveto(pC);
if(ret)
break;
if(pC->rowidIsValid)
{
*prowid = pC->lastRowid;
}
else if(pC->pseudoTableReg>0)
{
}
//else if(pC->pseudoTable)
//{
// *prowid = pC->iKey;
//}
else if(pC->nullRow || pC->pCursor==0)
{
ret = SQLITE_ERROR;
break;
}
else
{
if (pC->pCursor == NULL)
{
ret = SQLITE_ERROR;
break;
}
sqlite3BtreeKeySize(pC->pCursor, prowid);
*prowid = *prowid;
}
break;
}
sqlite3_mutex_leave(db->mutex);
return ret;
}
> I think, without to be 100% sure, that it is for the wrapper .NET
> System.Data.SQLite.
> I was myself in front of this code (to have this wrapper using the latest
> sqlite version).
> I ended up by removing all this code, meaning that if you don't call
> dispose() in your code, it will not be garbage collected.
> It is a risk I took, and it works so far.
>
> Best regards,
> Sylvain
>
> On Sat, Apr 17, 2010 at 8:07 PM, D. Richard Hipp wrote:
>
>>
>> On Apr 17, 2010, at 1:02 PM, Paul Shaffer wrote:
>>
>> > Due to changes in VdbeCursor structure, this code for 3.6.16 won't
>> > compile
>> > anymore:
>> >
>> > else if(pC->pseudoTable)
>> > {
>> > *prowid = pC->iKey;
>> > }
>> >
>>
>> Your application should not be messing with internal data structures
>> of SQLite, all of which are subject to change without notice (as you
>> have discovered.)
>>
>> Perhaps if you explain to us what you are trying to accomplish we will
>> be better able to help you.
>>
>>
>> > and for 3.6.23 would have to be replaced by something like this:
>> >
>> > else if(pC->pseudoTableReg>0)
>> > {
>> > //*prowid =
>> > }
>> >
>> > My problem is that after about an hour of reverse engineering I can't
>> > figure out a way to get the row id with the new code. Any help
>> > appreciated.
>> >
>> >
>> > ___
>> > sqlite-users mailing list
>> > sqlite-users at sqlite.org
>> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
>> D. Richard Hipp
>> drh at hwaci.com
>>
>>
>>
>> ___
>> sqlite-users mailing list
>> sqlite-users at sqlite.org
>> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Question on the VdbeCursor structure changes
I think, without to be 100% sure, that it is for the wrapper .NET
System.Data.SQLite.
I was myself in front of this code (to have this wrapper using the latest
sqlite version).
I ended up by removing all this code, meaning that if you don't call
dispose() in your code, it will not be garbage collected.
It is a risk I took, and it works so far.
Best regards,
Sylvain
On Sat, Apr 17, 2010 at 8:07 PM, D. Richard Hipp wrote:
>
> On Apr 17, 2010, at 1:02 PM, Paul Shaffer wrote:
>
> > Due to changes in VdbeCursor structure, this code for 3.6.16 won't
> > compile
> > anymore:
> >
> > else if(pC->pseudoTable)
> > {
> > *prowid = pC->iKey;
> > }
> >
>
> Your application should not be messing with internal data structures
> of SQLite, all of which are subject to change without notice (as you
> have discovered.)
>
> Perhaps if you explain to us what you are trying to accomplish we will
> be better able to help you.
>
>
> > and for 3.6.23 would have to be replaced by something like this:
> >
> > else if(pC->pseudoTableReg>0)
> > {
> > //*prowid =
> > }
> >
> > My problem is that after about an hour of reverse engineering I can't
> > figure out a way to get the row id with the new code. Any help
> > appreciated.
> >
> >
> > ___
> > sqlite-users mailing list
> > sqlite-users@sqlite.org
> > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
> D. Richard Hipp
> d...@hwaci.com
>
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
Re: [sqlite] Question on the VdbeCursor structure changes
On Apr 17, 2010, at 1:02 PM, Paul Shaffer wrote:
> Due to changes in VdbeCursor structure, this code for 3.6.16 won't
> compile
> anymore:
>
> else if(pC->pseudoTable)
> {
> *prowid = pC->iKey;
> }
>
Your application should not be messing with internal data structures
of SQLite, all of which are subject to change without notice (as you
have discovered.)
Perhaps if you explain to us what you are trying to accomplish we will
be better able to help you.
> and for 3.6.23 would have to be replaced by something like this:
>
> else if(pC->pseudoTableReg>0)
> {
> //*prowid =
> }
>
> My problem is that after about an hour of reverse engineering I can't
> figure out a way to get the row id with the new code. Any help
> appreciated.
>
>
> ___
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
D. Richard Hipp
d...@hwaci.com
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
[sqlite] Question on the VdbeCursor structure changes
Due to changes in VdbeCursor structure, this code for 3.6.16 won't compile
anymore:
else if(pC->pseudoTable)
{
*prowid = pC->iKey;
}
and for 3.6.23 would have to be replaced by something like this:
else if(pC->pseudoTableReg>0)
{
//*prowid =
}
My problem is that after about an hour of reverse engineering I can't
figure out a way to get the row id with the new code. Any help appreciated.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
