On Mon, Dec 05, 2005 at 08:23:19AM -0500, [EMAIL PROTECTED] wrote:
> > OK, so 1.11 is on CPAN which fixes this. However I have another bug
> > report about this not working for user defined functions, where I do
> > this:
> >
> > s = SvPV(result, len);
> > sqlite3_result_text(
On 5 Dec 2005, at 13:23, [EMAIL PROTECTED] wrote:
I added a test case (check-in [2798]) that checks to make sure
that sqlite3_result_text is able to deal with embedded '\000'
characters in a string. I appears to work fine. I cannot
reproduce the problem
Can you suggest other ways of
Matt Sergeant <[EMAIL PROTECTED]> wrote:
>
> OK, so 1.11 is on CPAN which fixes this. However I have another bug
> report about this not working for user defined functions, where I do
> this:
>
> s = SvPV(result, len);
> sqlite3_result_text( context, s, len, SQLITE_TRANSIENT
On 2 Dec 2005, at 13:07, [EMAIL PROTECTED] wrote:
Right. So it's retreival that's the issue when this occurs, because I
do:
int col_type = sqlite3_column_type(stmt, i);
and it returns SQLITE_TEXT, so I then do:
val = (char*)sqlite3_column_text(stmt, i);
which doesn't return a length
On 2 Dec 2005, at 08:07, [EMAIL PROTECTED] wrote:
Would sqlite3_column_bytes() return the right length there rather than
me doing strlen() on the resulting data?
yes it will.
Doh! In that case then 1.11 will head to CPAN with blobs working
transparently.
Matt Sergeant <[EMAIL PROTECTED]> wrote:
> On 1 Dec 2005, at 21:52, [EMAIL PROTECTED] wrote:
>
> > SQLite does has a separate BLOB type. But for TEXT types, SQLite
> > still works like Perl and carries around a length so that the string
> > can have embedded '\000' characters. I just added a
On 1 Dec 2005, at 21:52, [EMAIL PROTECTED] wrote:
SQLite does has a separate BLOB type. But for TEXT types, SQLite
still works like Perl and carries around a length so that the string
can have embedded '\000' characters. I just added a test to the
test suite to verify that this works.
Nathan Kurz <[EMAIL PROTECTED]> wrote:
>
> > So as far as I can tell, both SQLite and Perl are doing exactly what
> > they ought to be.
>
> That certainly could be argued, although it does seem to trap the
> unwary (like me) with fair regularity. One option for 'improving' it
> might be to make
On Thu, Dec 01, 2005 at 09:52:25PM -0500, [EMAIL PROTECTED] wrote:
> Suppose you do this:
>
>sqlite3_bind_text(pVm, 1, "abc\000xyz\000pq", 10, SQLITE_STATIC);
>
> If this is part of an INSERT, say, then you will insert a 10-character
> string that happens to contain a couple of extra \000
A very interesting discussion thread! Thanks to everyone who posted for
adding to my knowledge.
Bob Cochran
[EMAIL PROTECTED] wrote:
Matt Sergeant <[EMAIL PROTECTED]> wrote:
Perl has no concept of blobs. A scalar variable can be one of:
IV (integer)
UV (unsigned integer)
NV (double)
PV
Matt Sergeant <[EMAIL PROTECTED]> wrote:
> Perl has no concept of blobs. A scalar variable can be one of:
>
> IV (integer)
> UV (unsigned integer)
> NV (double)
> PV (string)
>
> so a blob is just a string - but perl carries a length around with it
> so you can have binary data in there.
>
On 1 Dec 2005, at 15:10, [EMAIL PROTECTED] wrote:
So in the example of $sth->execute($blob), if $blob contains an
integer, use sqlite3_bind_int64(), or if $blob contains a string
use sqlite3_bind_text(), or if $blob contains a blob, then use
sqlite3_bind_blob(), and so forth.
Is there
Jim Dodgen <[EMAIL PROTECTED]> wrote:
> Perl is mostly typeless, or more correctly has late dynamic binding. No way
> to
> tell between a scalar used as a string, or a blob. I see no down side in
> having
> to specify the SQL_BLOB type when access a BLOB field, I just would help to
> have
Perl is mostly typeless, or more correctly has late dynamic binding. No way to
tell between a scalar used as a string, or a blob. I see no down side in having
to specify the SQL_BLOB type when access a BLOB field, I just would help to
have know that.
JIm Dodgen
Quoting [EMAIL PROTECTED]:
On Thu, 1 Dec 2005, Matt Sergeant wrote:
> > Looking now at the DBI documentation, I see that values bound using
> > execute are 'usually treated as "SQL_VARCHAR" types unless the driver
> > can determine the correct type (which is rare)'. Because it is simple
> > to scan the string for NUL's, I
On Wed, Nov 30, 2005 at 05:10:19PM -0600, Jim Dodgen wrote:
> > What do you get back (using the command-line client) when you
> > ask for LENGTH(x) or QUOTE(x) instead of just the column x?
>
> sqlite> select length(val) from foo;
> 3
> sqlite> select quote(val) from foo;
> 'MZP'
>
> strange,
thanks for the help,
I tried one ot the workarounds noted in
http://rt.cpan.org/NoAuth/Bug.html?id=14595
which had you force the data type to SQL_BLOB
this makes things work!! horray!!
I included the complete test program for reference to others
code snippit
use DBI
Nathan Kurz <[EMAIL PROTECTED]> wrote:
> On Wed, Nov 30, 2005 at 04:36:30PM -0600, Jim Dodgen wrote:
>
> The Perl interface through DBD-SQLite-1.09 is broken with regard to
> blobs. It binds the result as text, thus doesn't handle NUL's.
>
> I've submitted a patch
I am having a problem with blobs, I seem to insert ok but only get three (3)
bytes when I query it back. yes I am setting LongReadLen. any ideas?
thanks
Jim
I'm using sqlite 3.2.7, 1.09 and of the perl module also code and test results
are below.
also when I use the command line sqlite3 I
19 matches
Mail list logo
