On 10/31/16, mark wrote:
> On Mon Oct 31, 2016 at 04:04:00PM -0400, Richard Hipp wrote:
>> Is this reproducible?
>
> Yes... in that I can reliably get it to segfault. Duplicating the build
> and/or statements leading up to the fault outside of my environment
> is not so easy.
Is this reproducible?
Can you share with us the schema of the database file that was
connected when this error occurred?
On 10/31/16, mark wrote:
> Operating system: OpenBSD 6.0
> DBD::SQLite: 1.51_06
> sqlite:3.15.0
>
> Program received signal SIGSEGV,
Operating system: OpenBSD 6.0
DBD::SQLite: 1.51_06
sqlite:3.15.0
Program received signal SIGSEGV, Segmentation fault.
sqlite3Step (p=0xb1480c37e08) at sqlite3.c:82102
82102 pCrsr = pC->uc.pCursor;
(gdb) list
82097
82098 assert( pOp->p1>=0 && pOp->p1nCursor );
82099
On 10/31/16, David Raymond wrote:
> Going through the documentation at http://www.sqlite.org/arch.html
> In the Parser section there's a link for Lemon:
> http://www.sqlite.org/lemon.html which is coming up as page not found.
Should be fixed now. Thanks.
--
D. Richard
Going through the documentation at http://www.sqlite.org/arch.html
In the Parser section there's a link for Lemon:
http://www.sqlite.org/lemon.html which is coming up as page not found.
___
sqlite-users mailing list
sqlite-users@mailinglists.sqlite.org
> It guess it comes down to what one wants from "INTEGER PRIMARY KEY
AUTOINCREMENT"
What I would want, ...expect, is that a primary key autoincrement column
would be left completely alone. And if was altered, it was altered on
accident. I always thought "integer primary key" was synonymous with
On 10/27/16, Adam Goldman wrote:
> I expected the test case below to print 5679, but it prints 1235
> instead. I tested under a few versions including 3.15.0. It's a bit of a
> corner case and I worked around it in my application, but I guess it's a
> bug.
>
> CREATE TABLE foo
On Fri Oct 28, 2016 at 05:48:48PM +0700, Dan Kennedy wrote:
> On 10/28/2016 05:39 PM, no...@null.net wrote:
> > Hi Rowan,
> >
> > On Fri Oct 28, 2016 at 06:19:59PM +0800, Rowan Worth wrote:
> > > Every sqlite_stmt you use *must* be finalized via sqlite3_finalize.
> > > I'm not exactly sure what
I haven't seen anything to say what journalling is being used
(Rollback, WAL or none). If the latter then SQLite will have nothing
to revert to on error.
Paul
www.sandersonforensics.com
skype: r3scue193
twitter: @sandersonforens
Tel +44 (0)1326 572786
9 matches
Mail list logo