On 2015-09-22 04:36 AM, James K. Lowden wrote:
> On Mon, 21 Sep 2015 11:19:16 +0200
> "R.Smith" wrote:
>
>>
>> This is the entire point of a database - allowing multiple things to
>> see the data. A system which only allows one thread to read data is
>> just a file-handler.
> ..//
> Not to be
On Mon, 21 Sep 2015 11:19:16 +0200
"R.Smith" wrote:
> On 2015-09-21 01:53 AM, Nicolas J?ger wrote:
> > hi,
> >
> >
> > Scott Robison wrote:
> >
> >> 3. Some time passes and some external process may alter the schema.
> >>
> > is it really possible ? if the answer is yes (I thought when a
> >
Thank you all for your replies.
As suggested, I am going to call sqlite3_column_count each time (after
the first sqlite3_step).
On Mon, Sep 21, 2015 at 5:57 PM, Scott Robison
wrote:
> On Mon, Sep 21, 2015 at 5:48 AM, Richard Hipp wrote:
>
>> On 9/21/15, Dominique Devienne wrote:
>> > On Sun,
On 21 September 2015 at 16:36, Simon Slavin wrote:
>
> On 21 Sep 2015, at 8:29am, Rowan Worth wrote:
>
> > 1) Statement is prepared
> > 2) Statement is stepped
> > 3) Statement is reset
> > 4) ... time passes ...
> > 5) Statement is stepped
> > 6) Statement is reset
> > 7) ... time passes ...
>
gwenn wrote:
> If there is no way to know that the statement has been recompiled, I
> guess that the column count should not be cached...
SQLite already caches it for you (and properly changes it when recompiling):
SQLITE_API int SQLITE_STDCALL sqlite3_column_count(sqlite3_stmt *pStmt){
Vdbe
On 21 September 2015 at 14:38, Simon Slavin wrote:
> As expected, ALTER TABLE acts like INSERT: it's a change which requires an
> exclusive lock. So just as the documentation says, in a normal journal
> mode you can't make a change while the database is locked (which it is
> during a SELECT),
On Sun, Sep 20, 2015 at 4:10 PM, Igor Tandetnik wrote:
> On 9/20/2015 9:55 AM, gwenn wrote:
>
>> If there is no way to know that the statement has been recompiled, I
>> guess that the column count should not be cached...
>>
>
> You could use sqlite3_prepare (no _v2), then you'd get an error on
On 2015-09-21 11:18 AM, Rowan Worth wrote:
> On 21 September 2015 at 16:36, Simon Slavin wrote:
>
>> On 21 Sep 2015, at 8:29am, Rowan Worth wrote:
>>
>>> 1) Statement is prepared
>>> 2) Statement is stepped
>>> 3) Statement is reset
>>> 4) ... time passes ...
>>> 5) Statement is stepped
>>> 6)
On 2015-09-21 01:53 AM, Nicolas J?ger wrote:
> hi,
>
>
> Scott Robison wrote:
>
>> 3. Some time passes and some external process may alter the schema.
>>
> is it really possible ? if the answer is yes (I thought when a process open a
> communication with
> the DB, other processes can't alter
On Mon, Sep 21, 2015 at 5:48 AM, Richard Hipp wrote:
> On 9/21/15, Dominique Devienne wrote:
> > On Sun, Sep 20, 2015 at 4:10 PM, Igor Tandetnik
> wrote:
> >
> >> On 9/20/2015 9:55 AM, gwenn wrote:
> >>
> >>> If there is no way to know that the statement has been recompiled, I
> >>> guess that
On 21 Sep 2015, at 8:29am, Rowan Worth wrote:
> 1) Statement is prepared
> 2) Statement is stepped
> 3) Statement is reset
> 4) ... time passes ...
> 5) Statement is stepped
> 6) Statement is reset
> 7) ... time passes ...
> etc. etc.
>
> The assertion seems to be that if the return value of
On 9/21/15, Dominique Devienne wrote:
> On Sun, Sep 20, 2015 at 4:10 PM, Igor Tandetnik wrote:
>
>> On 9/20/2015 9:55 AM, gwenn wrote:
>>
>>> If there is no way to know that the statement has been recompiled, I
>>> guess that the column count should not be cached...
>>>
>>
>> You could use
I did the experiment. I used two Terminal windows accessing the same database.
It's not quite the right experiment because I can't figure out how to make the
shell tool stop in the middle of a SELECT. So instead I used a transaction to
keep the database locked between two SELECT commands.
On 21 Sep 2015, at 12:32am, Scott Robison wrote:
> 4. Step through the prepared statement from #1 again after doing any
> necessary reset. No finalize / re-prepare step.
I believe that if you have done the first _step() then the SELECT will not
notice any schema change until you have received
hi,
Scott Robison wrote:
>
> 3. Some time passes and some external process may alter the schema.
>
is it really possible ? if the answer is yes (I thought when a process open a
communication with
the DB, other processes can't alter the DB), for me that would mean that the
design(s) of the
On Sun, Sep 20, 2015 at 5:53 PM, Nicolas J?ger
wrote:
> hi,
>
>
> Scott Robison wrote:
>
> >
> > 3. Some time passes and some external process may alter the schema.
> >
>
> is it really possible ? if the answer is yes (I thought when a process
> open a communication with
> the DB, other
On Sun, Sep 20, 2015 at 5:47 PM, Simon Slavin wrote:
>
> On 21 Sep 2015, at 12:32am, Scott Robison wrote:
>
> > 4. Step through the prepared statement from #1 again after doing any
> > necessary reset. No finalize / re-prepare step.
>
> I believe that if you have done the first _step() then the
On Sun, Sep 20, 2015 at 8:11 AM, Simon Slavin wrote:
>
> On 20 Sep 2015, at 2:55pm, gwenn wrote:
>
> > But if a column is added to one table in your database, your statement
> > is successfully/transparently recompiled (when calling sqlite3_step)
> > and the column count may be changed.
>
>
Sorry for my bad description.
Imagine that you have a cache of statements (like in tclsqlite.c)
created using sqlite3_prepare_v2.
And you want to avoid calling sqlite3_column_count/sqlite3_column_name
each time you reuse (sqlite3_step) the same statement (with Java (JNI)
or Go (cgo), a native call
On 20 Sep 2015, at 2:55pm, gwenn wrote:
> But if a column is added to one table in your database, your statement
> is successfully/transparently recompiled (when calling sqlite3_step)
> and the column count may be changed.
Let's assume that you have not used any PRAGMAs to defeat the
On 9/20/2015 9:55 AM, gwenn wrote:
> If there is no way to know that the statement has been recompiled, I
> guess that the column count should not be cached...
You could use sqlite3_prepare (no _v2), then you'd get an error on
schema change. You would then re-prepare the statement and update
On 2015-09-19 06:41 PM, gwenn wrote:
> SQLITE_SCHEMA is returned only on failure.
> But, here, there is not failure.
>
> Maybe I should not store the column count ?
> Maybe I should look at schema version
> (http://sqlite.org/pragma.html#pragma_schema_version):
> "The schema version is used by
On 19 Sep 2015, at 5:41pm, gwenn wrote:
> Is there a better solution ?
Why do you want to know when the statement has been recompiled while you're in
the middle of processing a SELECT command ? Are you doing something that might
make you pause for a long time before executing your last
SQLITE_SCHEMA is returned only on failure.
But, here, there is not failure.
Maybe I should not store the column count ?
Maybe I should look at schema version
(http://sqlite.org/pragma.html#pragma_schema_version):
"The schema version is used by SQLite each time a query is executed to
ensure that
On Sat, 19 Sep 2015 11:29:37 +0200, gwenn
wrote:
>Hello,
>Is there any way to know when a prepared statement is recompiled ?
>For example:
>
>rc = sqlite3_prepare_v2(db, "SELECT * FROM test", -1, , NULL);
>...
>cc = sqlite3_column_count(stmt);
>...
>rc = sqlite3_exec(db, "ALTER TABLE test ADD
Hi gwenn,
Maybe you are talking about something I don't understand, or I don't understand
what you are
talking about...
I would like somebody tells if I'm wrong or right,
first in your email you have both :
> >>rc = sqlite3_prepare_v2(db, "SELECT * FROM test", -1, , NULL);
> >>...
> >>...
>
Hello,
Is there any way to know when a prepared statement is recompiled ?
For example:
rc = sqlite3_prepare_v2(db, "SELECT * FROM test", -1, , NULL);
...
cc = sqlite3_column_count(stmt);
...
rc = sqlite3_exec(db, "ALTER TABLE test ADD COLUMN data DEFAULT
'missing'", NULL, NULL, NULL);
...
rc =
Le Sat, 19 Sep 2015 15:21:44 +0200,
Kees Nuyt a ?crit :
> On Sat, 19 Sep 2015 11:29:37 +0200, gwenn
> wrote:
>
> >Hello,
> >Is there any way to know when a prepared statement is recompiled ?
> >For example:
> >
> >rc = sqlite3_prepare_v2(db, "SELECT * FROM test", -1, , NULL);
> >...
> >cc =
28 matches
Mail list logo
