Glad I could help find something, hope I put you in the right direction with
the source sample.
In the meantime I've moved to standard tables due to other limitations
imposed by FTS1/2.
Scott Hess wrote:
>
> OK, there's definite meat, here. I have other reports of users seeing
> this problem.
OK, there's definite meat, here. I have other reports of users seeing
this problem. It's specifically related to doing UPDATE against an
fts1 or fts2 table. INSERT and DELETE both work fine. As far as I
can tell, UPDATE may have never worked, or may have worked only in
specific circumstances.
looks like the file came in without CRLF, here goes:
--
#include "../sqlite-3_3_8/sqlite3.h"
#include
static sqlite3* db;
void exec_dml(const TCHAR* cmd)
{
sqlite3_stmt* vm;
here's a file, plain.cpp, which demonstrates the problem.
if you're compiling on linux and not windows you'll have to do a few trivial
changes.
_T("string") is used to define a unicode string
TCHAR is WORD/SHORT/etc
Scott Hess wrote:
>
> There haven't been any changes to the fts1 code!
>
>
There haven't been any changes to the fts1 code!
Your best bet is to put together a .c file with a main() which causes
the problem. Or a tcl script, or anything that would allow someone to
see things locally. The problem right now is that there's no
particular way for any of us to find the
it looks like fts1/2 return an ascii string in disguise of a unicode string
after an update to the data.
John Stanton wrote:
>
> In that case your problem will be in your code, specifically in the
> function which gives you a pointer to the data.
>
> Show us your code.
>
> ohadp wrote:
>>
It returns 3 (text) both before and after the update.
I bet someone who's familiar with fts1 code would immediately spot the
change that caused this encoding bug
Dan Kennedy-4 wrote:
>
> On Thu, 2007-01-11 at 15:00 -0800, ohadp wrote:
>> here's the detailed description of the apparent bug:
>>
On Thu, 2007-01-11 at 15:00 -0800, ohadp wrote:
> here's the detailed description of the apparent bug:
>
> i'm using the _16 versions for getting text from an fts1 table.
> if i insert data and select, i get good data, meaning my call to
> sqlite3_column_text16(..) returns a pointer to a UNICODE
I'm not using the various 'bind' calls but simply executing SQL
inserts/updates/querys with _sqlite3_prepare, _sqlite3_step.
notice that the insert comes through as unicode, the update is recognized as
unicode but stored as ascii.
i looked into the code one level deeper and it looks like the
This is happening only with FTS1.
With a normal table everything comes back normally.
ohadp wrote:
>
> here's the detailed description of the apparent bug:
>
> i'm using the _16 versions for getting text from an fts1 table.
> if i insert data and select, i get good data, meaning my call to
Are you absolutely, positively certain that you're calling
sqlite3_bind_text16() when setting up the update? I ask because I
recently spent a long afternoon tracking down that basic mistake :-).
-scott
On 1/11/07, ohadp <[EMAIL PROTECTED]> wrote:
here's the detailed description of the
here's the detailed description of the apparent bug:
i'm using the _16 versions for getting text from an fts1 table.
if i insert data and select, i get good data, meaning my call to
sqlite3_column_text16(..) returns a pointer to a UNICODE string.
if i update and then select, my call to
In that case your problem will be in your code, specifically in the
function which gives you a pointer to the data.
Show us your code.
ohadp wrote:
i'm linking with it and calling the api directly.
i think that sqlite3.exe doesn't have fts1 support in it.
John Stanton wrote:
How are you
i'm linking with it and calling the api directly.
i think that sqlite3.exe doesn't have fts1 support in it.
John Stanton wrote:
>
> How are you calling Sqlite? Have you tried sqlite3.exe?
>
> ohadp wrote:
>> Scott Hess <[EMAIL PROTECTED]> writes:
>>
>>
>>
>>> CREATE VIRTUAL TABLE t USING
On 1/11/07, ohadp <[EMAIL PROTECTED]> wrote:
Scott Hess <[EMAIL PROTECTED]> writes:
> CREATE VIRTUAL TABLE t USING fts1(content);
> INSERT INTO t (rowid, content) VALUES (1, 'this is a test');
> UPDATE t SET content = 'that was a test' WHERE rowid = 1;
>
> -- The following is returning
How are you calling Sqlite? Have you tried sqlite3.exe?
ohadp wrote:
Scott Hess <[EMAIL PROTECTED]> writes:
CREATE VIRTUAL TABLE t USING fts1(content);
INSERT INTO t (rowid, content) VALUES (1, 'this is a test');
UPDATE t SET content = 'that was a test' WHERE rowid = 1;
-- The
Scott Hess <[EMAIL PROTECTED]> writes:
>
> CREATE VIRTUAL TABLE t USING fts1(content);
> INSERT INTO t (rowid, content) VALUES (1, 'this is a test');
> UPDATE t SET content = 'that was a test' WHERE rowid = 1;
>
> -- The following is returning 'gibberish here' for me:
> SELECT content
inserts work
once i update my fts1 table and then select data from it, i get gibberish.
anybody seen something like this ?
18 matches
Mail list logo
