Skip Menu |

This queue is for tickets about the DBD-SQLite CPAN distribution.

Report information
The Basics
Id: 15756
Status: resolved
Priority: 0/
Queue: DBD-SQLite

People
Owner: Nobody in particular
Requestors:
Cc:
AdminCc:

Bug Information
Severity: Normal
Broken in: 1.09
Fixed in: (no value)



Subject: Selectrow_arrayref() with prepared statement doesnt work
This small example demostrates the problem. First call to selectrow_arrayref works but secondone doesnt. #!/usr/bin/perl use DBI; my $dbh = DBI->connect("dbi:SQLite:dbname=/tmp/dbfile.db","",""); my $stm = $dbh->prepare('SELECT * FROM ipaccount WHERE ip=?'); $dbh->selectrow_arrayref($stm, undef, 1); $dbh->selectrow_arrayref($stm, undef, 2); DBD::SQLite::db selectrow_arrayref failed: not an error(21) at dbdimp.c line 371 at /tmp/t line 7. With trace(9): DBI::db=HASH(0x81b9ba4) trace level set to 0x0/9 (DBI @ 0x0/0) in DBI 1.48-ithread (pid 3485) Note: perl is running without the recommended perl -w option -> selectrow_arrayref for DBD::SQLite::db (DBI::db=HASH(0x81b87dc)~0x81b9ba4 DBI::st=HASH(0x81b9c7c) undef 1) thr#804c008 sqlite trace: bind into 0x804cd10: 1 => 1 (0) pos 0 at dbdimp.c line 442 sqlite trace: params left in 0x804cd10: 0 at dbdimp.c line 338 sqlite trace: bind 0 type 0 as 1 at dbdimp.c line 339 sqlite trace: Execute returned 4 cols at dbdimp.c line 390 sqlite trace: exec ok - 0 rows, 4 cols at dbdimp.c line 412 sqlite trace: numFields == 4, nrow == 0 at dbdimp.c line 458 <- selectrow_arrayref= undef at /tmp/t line 6 -> selectrow_arrayref for DBD::SQLite::db (DBI::db=HASH(0x81b87dc)~0x81b9ba4 DBI::st=HASH(0x81b9c7c) undef 2) thr#804c008 sqlite trace: bind into 0x804cd10: 1 => 2 (0) pos 0 at dbdimp.c line 442 sqlite trace: re-prepare statement at dbdimp.c line 321 sqlite trace: params left in 0x804cd10: 0 at dbdimp.c line 338 sqlite trace: bind 0 type 0 as 2 at dbdimp.c line 339 sqlite error 21 recorded: not an error at dbdimp.c line 371 !! ERROR: 21 'not an error(21) at dbdimp.c line 371' (err#0) <- selectrow_arrayref= undef at /tmp/t line 7 DBD::SQLite::db selectrow_arrayref failed: not an error(21) at dbdimp.c line 371 at /tmp/t line 7. -> DESTROY for DBD::SQLite::db (DBI::db=HASH(0x81b9ba4)~INNER) thr#804c008 ERROR: 21 'not an error(21) at dbdimp.c line 371' (err#0) <- DESTROY= undef
Atached patch fixes this. I think it also fixes bug: http://rt.cpan.org/NoAuth/Bug.html?id=9643 Some tests "fails" with patch, but they could be fixes by: undef $sth; Patch works by resetting old statement if it being reused, and only finalises it when it is being destroyed. -- Tomi Leppikangas
Download patsi
application/octet-stream 2.3k

Message body not shown because it is not plain text.

Le Mar. Nov. 15 16:32:29 2005, guest a écrit : Show quoted text
> Atached patch fixes this. I think it also fixes bug: > > http://rt.cpan.org/NoAuth/Bug.html?id=9643 > > Some tests "fails" with patch, but they could be fixes by: > undef $sth; > > Patch works by resetting old statement if it being reused, and only > finalises it when it is being destroyed. > -- > Tomi Leppikangas
this patch does not resolve the same issue using selectrow_array more than one time with a prepared statement.
From: Srand
Le Dim. Avr. 23 16:52:29 2006, guest a écrit : Show quoted text
> Le Mar. Nov. 15 16:32:29 2005, guest a écrit :
> > Atached patch fixes this. I think it also fixes bug: > > > > http://rt.cpan.org/NoAuth/Bug.html?id=9643 > > > > Some tests "fails" with patch, but they could be fixes by: > > undef $sth; > > > > Patch works by resetting old statement if it being reused, and only > > finalises it when it is being destroyed. > > -- > > Tomi Leppikangas
> > this patch does not resolve the same issue using selectrow_array more > than one time with a prepared statement.
see http://rt.cpan.org/Public/Bug/Display.html?id=18878
From: MSERGEANT [...] cpan.org
On Tue Nov 15 16:32:29 2005, guest wrote: Show quoted text
> Atached patch fixes this. I think it also fixes bug: > > http://rt.cpan.org/NoAuth/Bug.html?id=9643 > > Some tests "fails" with patch, but they could be fixes by: > undef $sth; > > Patch works by resetting old statement if it being reused, and only > finalises it when it is being destroyed.
OK, this seems the sanest of the patches I've had about this issue, so I've applied it and fixed all the failing tests. Thanks!