It looks like a bug.
Try the follwing code with DBD::SQLite2 (previous version), and it will show the correct result.
use strict; use warnings; use Data::Dumper; use DBI; my $dbh = DBI->connect('DBI:SQLite2:dbname=test_blob.db', '', ''); $dbh->{sqlite_handle_binary_nulls}=1; $dbh->do('CREATE TABLE test_blob( Bindata BLOB )'); my $bindata = "ABC" . "\x00" . "DEFINITIVELY"; print Data::Dumper->Dump([$bindata],['original']); my $sth1 = $dbh->prepare('INSERT INTO test_blob VALUES(?)' ); $sth1->execute($bindata); my $sth2 = $dbh->prepare('SELECT Bindata FROM test_blob'); $sth2->execute(); my $row = $sth2->fetch(); my $fetched_data = $row->[0]; print Data::Dumper->Dump([$fetched_data],['fetched']);
Results:
$original = 'ABCDEFINITIVELY'; $fetched = 'ABCDEFINITIVELY';
Moreover, the data was inserted even using SQLite 3.
If you want to be sure, just check if the file contains the string you have inserted after char 0x0.
$ grep DEFINITIVELY test_blob.db Binary file test_blob.db matches
Therefore, the bug is in the retrieval function. (Notice that the standalone sqlite3 binary program gets the same truncated result.)
In reply to Re: How to store NUL characters into SQLite BLOB ?
by rnahi
in thread How to store NUL characters into SQLite BLOB ?
by dont_you
| For: | Use: | ||
| & | & | ||
| < | < | ||
| > | > | ||
| [ | [ | ||
| ] | ] |