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;
sqlite3_prep
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!
>
> Y
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 prob
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:
>> i
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 stor
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 appare
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 sqlite3_c
The precompiled binaries... work :-)
i stepped in and it seems like the problem is an ascii/unicode problem.
what happens is that i call sqlite3_column_text16 and get back an ASCII
string...
i haven't touched the rest of my code so let me ask if something's changed
in this latest release ?
Scott
I think there's a dll on the downloads page, could you please try that?
Sorry to put you through this. It's generally very hard to debug
problems remotely, having a repeatable test case running in an
environment everyone can agree on is essential.
-scott
On 1/11/07, ohadp <[EMAIL PROTECTED]>
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 ca
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 'g
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 followin
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
On 1/11/07, Ohad Eder-Pressman <[EMAIL PROTECTED]> wrote:
inserts work
once i update my fts1 table and then select data from it, i get gibberish.
anybody seen something like this ?
Anything is possible - suggest you indicate the version you're using,
and provide an SQL script which demonstrate
20 matches
Mail list logo
