what about the differences between the FULL and PARTIAL modes of pragma
synchronous ?
--
View this message in context:
http://www.nabble.com/how-can-i-speed-up-inserts---tf3186848.html#a8860860
Sent from the SQLite mailing list archive at Nabble.com.
when you say much less do you mean one in 1,000 or 1 in 1,000,000 ?
Gerry Snyder-3 wrote:
>
> If you really can't get more than 4-5 in a batch, it's your call whether
> the time saving is worth the risk. BTW, the problem rate should be much
> less than one in ten thousand.
>
> Gerry
>
>
luckily this isn't mission critical failure, i'll take the risk that one out
of ten thousand users experiences database corruption.
i can only batch the inserts into maybe 4-5 a time, don't know how much of
an improvement that will be...
Dennis Cote wrote:
>
> ohadp wrote:
>>
holy smokes that pragma just made my several hundred inserts take half a
second compared to 30 seconds earlier.
thanks!
DragonK wrote:
>
> On 2/7/07, Ohad Eder-Pressman <[EMAIL PROTECTED]> wrote:
>>
>> i've got sqlite compiled with visual-studio, with all the default
>> options,
>> didn't
s 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. More as it's available.
>
> -scott
>
>
> On
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!
>
>
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.
&
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
etting 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 apparent bug:
>>
>> i'm u
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,
to sqlite3_column_text16(..) returns a
pointer to an ASCII string instead of a UNICODE one. The string if
interpreted visually is the right string, but calling the unicode version of
the function and receiving an ascii string is a problem :-)
ohadp wrote:
>
> The precompiled binaries... work :
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:
>>
>>
&
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
14 matches
Mail list logo
