On Sat, 13 Jul 2013 00:09:36 -0600
"Keith Medcalf" wrote:
> UPDATE WHERE CURRENT OF CURSOR has been part of SQL since about, oh,
> 1969.
(I assume that's dramatic license.)
> Now then SQLite does not support the FOR UPDATE OF clause when
> defining a cursor (ie, doing a prepare) which is int
> Richard Hipp said on Saturday, 13 July, 2013 11:59:
> > I don't know. It works entirely as expected. If I move a row (via
> > update) that I have already visited into a position where it is "yet
> > to be visited", then I will visit it twice -- both times exactly when
> > and where expected.
On Sat, Jul 13, 2013 at 1:53 PM, Keith Medcalf wrote:
>
> I don't know. It works entirely as expected. If I move a row (via
> update) that I have already visited into a position where it is "yet to be
> visited", then I will visit it twice -- both times exactly when and where
> expected.
>
Ple
a deficit in wattage and
understanding.
> -Original Message-
> From: sqlite-users-boun...@sqlite.org [mailto:sqlite-users-
> boun...@sqlite.org] On Behalf Of Igor Tandetnik
> Sent: Saturday, 13 July, 2013 07:37
> To: sqlite-users@sqlite.org
> Subject: Re: [sqlite] Another
On 7/13/2013 1:36 AM, Keith Medcalf wrote:
Of course, the behaviour is not actually "undefined" -- it is perfectly determinable and
entirely predictable and reasonable. However, if one does not understand the factors which
determine the behaviour then, for you, the behaviour is undefined. In
> It's not SQLite's "problem", I suppose. If it works as intended, it's
> not a bug. Where we disagree is over whether that intention best
> serves the application programmer.
> You think it's OK: he made his bed and now he can lie in it. Modify
> the table you haven't finished selecting, and
> The major unexpected thing here is how SQLite deals with a case where
> two different connections (which may be from different apps on
> different computers) both have uncommitted changes. I think
> explaining things using this as the key point may make explaining the
> other aspects unnecessar
rg] On Behalf Of Richard Hipp
> Sent: Friday, 12 July, 2013 14:03
> To: General Discussion of SQLite Database
> Subject: Re: [sqlite] Another 2 questions about SQLite
>
> On Fri, Jul 12, 2013 at 3:01 PM, Igor Tandetnik
> wrote:
>
> > On 7/12/2013 12:30 PM, James K. Lowden wr
On Fri, 12 Jul 2013 14:25:36 -0400
Igor Tandetnik wrote:
> >it is very much SQLite's job to prevent logical
> > programming errors from corrupting the data.
>
> Define "the data". The database file remains perfectly intact, no
> corruption there. Your internal state might be corrupted - but how
On Fri, 12 Jul 2013 16:02:37 -0400
Richard Hipp wrote:
> On Fri, Jul 12, 2013 at 3:01 PM, Igor Tandetnik
> wrote:
>
> > On 7/12/2013 12:30 PM, James K. Lowden wrote:
> >
> >> The documented behavior is - if you modify the data as you iterate
> >>> over that same data, the results are unpredicta
On 12 Jul 2013, at 9:02pm, Richard Hipp wrote:
> Proposed documentation enhancement here:
> http://www.sqlite.org/draft/isolation.html
I hope you don't mind that I posted this publicly. It's a bit strong for a
public forum, but I suspect that other readers of this forum might want to
chime i
On Fri, Jul 12, 2013 at 3:01 PM, Igor Tandetnik wrote:
> On 7/12/2013 12:30 PM, James K. Lowden wrote:
>
>> The documented behavior is - if you modify the data as you iterate
>>> over that same data, the results are unpredictable.
>>>
>>
>> Where does it say that?
>>
>
> You got me here. The beha
On 7/12/2013 12:30 PM, James K. Lowden wrote:
The documented behavior is - if you modify the data as you iterate
over that same data, the results are unpredictable.
Where does it say that?
You got me here. The behavior doesn't appear to be documented, and it
probably should. The closest I co
On 7/12/2013 12:30 PM, James K. Lowden wrote:
On Mon, 08 Jul 2013 00:37:55 -0400
Igor Tandetnik wrote:
I don't believe it's SQLite's job to ensure the programmer doesn't
shoot herself in the foot. After all, you don't expect, say, the C++
compiler to prevent you from destroying an object while
Quoth "James K. Lowden" , on 2013-07-12 12:30:13
-0400:
> as the first one reads it. In fact, I'd be interested if you could
> point to a single standard C library function that, when called
> out-of-sequence, doesn't return an error but permits the process to
> proceed destructively.
free().
On 12 Jul 2013, at 5:30pm, James K. Lowden wrote:
> There is no "SQLITE_OK_BUT_YOU_ARE_ON_YOUR_OWN" afaik.
This is the best idea ever. I vote it gets included in SQLite4.
Simon.
___
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.or
On Mon, 08 Jul 2013 00:37:55 -0400
Igor Tandetnik wrote:
> I don't believe it's SQLite's job to ensure the programmer doesn't
> shoot herself in the foot. After all, you don't expect, say, the C++
> compiler to prevent you from destroying an object while another part
> of the program holds a poin
On 7/8/2013 12:09 AM, James K. Lowden wrote:
On Thu, 04 Jul 2013 16:08:38 -0400
Igor Tandetnik wrote:
On 7/4/2013 3:15 PM, James K. Lowden wrote:
This weird case is one of (I would say) misusing the connection.
IMO SQLite should return an error if prepare is issued on a
connection for which a
On 7/8/2013 12:09 AM, James K. Lowden wrote:
In real life, programs are complex, and libraries are misused
(intentionally or not). SQLite's job is to be a DBMS: to provide
predictable, safe access to the database, defending against errors
foreign and domestic (i.e. hardware errors, OS errors, *a
On Thu, 04 Jul 2013 16:08:38 -0400
Igor Tandetnik wrote:
> On 7/4/2013 3:15 PM, James K. Lowden wrote:
> > This weird case is one of (I would say) misusing the connection.
> > IMO SQLite should return an error if prepare is issued on a
> > connection for which a previous prepare was not finalized
On Thu, 4 Jul 2013 20:36:10 +0100
Simon Slavin wrote:
> On 4 Jul 2013, at 8:15pm, James K. Lowden
> wrote:
>
> > It doesn't usually matter, right? The fact that the atomic SELECT
> > is spread out across N function calls is irrelevant if they are
> > executed in uninterrupted sequence, because
On Thu, 4 Jul 2013 15:15:14 -0400, "James K. Lowden"
wrote:
> This weird case is one of (I would say) misusing the connection. IMO
> SQLite should return an error if prepare is issued on a connection for
> which a previous prepare was not finalized or reset. That would
> forestall discussions l
On 7/4/2013 3:15 PM, James K. Lowden wrote:
This weird case is one of (I would say) misusing the connection. IMO
SQLite should return an error if prepare is issued on a connection for
which a previous prepare was not finalized or reset. That would
forestall discussions like, this and prevent co
On 7/4/2013 3:15 PM, James K. Lowden wrote:
If two processes sharing a connection...
This is a physical impossibility. There ain't no such thing as two
processes sharing a connection.
--
Igor Tandetnik
___
sqlite-users mailing list
sqlite-users@sql
On 4 Jul 2013, at 8:15pm, James K. Lowden wrote:
> It doesn't usually matter, right? The fact that the atomic SELECT is
> spread out across N function calls is irrelevant if they are executed
> in uninterrupted sequence, because other connections are blocked from
> modifying the affected tables
On Thu, Jul 4, 2013 at 9:15 PM, James K. Lowden wrote:
> On Mon, 01 Jul 2013 23:59:15 -0400
> Igor Tandetnik wrote:
>
> > > 2. Trying to re-use a single connection to issue a second query
> > > before finalizing the first one should return an error
> >
> > No it should not, and does not. Try it.
On Tue, 2 Jul 2013 11:57:43 +0100
Simon Slavin wrote:
> The SELECT statement is fine and consistent. But the SELECT
> statement is all of _prepare(), _step(), and _finalize(). Igor is
> pointing out that that if you stop before _step() has returned
> SQLITE_DONE then you haven?t /done/ a SELECT
On Mon, 01 Jul 2013 23:59:15 -0400
Igor Tandetnik wrote:
> > 2. Trying to re-use a single connection to issue a second query
> > before finalizing the first one should return an error
>
> No it should not, and does not. Try it.
>
> > because the library is being improperly used.
>
> That may
On 2 Jul 2013, at 3:33am, James K. Lowden wrote:
> Igor Tandetnik wrote:
>
>> On 6/30/2013 11:13 PM, Igor Korot wrote:
>>> Well I will use another statement variable as in the sample code.
>>> My questions was: if I call delete on the record that was just
>>> retrieved in another query will th
On 7/1/2013 11:30 PM, James K. Lowden wrote:
Restricting ourselves to one process, I can think of two ways that
might go:
1. With two connections, one connection or the other will wait.
SELECT will return 0 or 10 rows.
Yes, between two connection, normal transaction isolation rules apply,
wh
On Mon, 01 Jul 2013 23:00:27 -0400
Igor Tandetnik wrote:
> On 7/1/2013 10:33 PM, James K. Lowden wrote:
> > Igor Tandetnik wrote:
> >> If you change data that a live SELECT statement is iterating over,
> >> the outcome is unpredictable. It may appear to work, it may skip
> >> rows, it may return
On 7/1/2013 10:33 PM, James K. Lowden wrote:
On Sun, 30 Jun 2013 23:27:23 -0400
Igor Tandetnik wrote:
If you change data that a live SELECT statement is iterating over,
the outcome is unpredictable. It may appear to work, it may skip
rows, it may return some rows more than once
Really? That'
On Sun, 30 Jun 2013 23:27:23 -0400
Igor Tandetnik wrote:
> On 6/30/2013 11:13 PM, Igor Korot wrote:
> > Well I will use another statement variable as in the sample code.
> > My questions was: if I call delete on the record that was just
> > retrieved in another query will this delete affects it?
I wish.
I need to remove those records from another table as well. That's why I
need to retrieve playerid first.
So once again: will the delete affect the outer looping SQLite statement?
I hate to be the one asking the obvious questions, but why are you not using a trigger or or a foreign key to
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 30/06/13 20:17, Igor Korot wrote:
> Well I'm not familiar with SQLite internals, but one thing for sure:
> why go thru the process if you can avoid it?
You are trying to do premature optimization.
Note the "Lite" in the SQLite. It is already des
On 6/30/2013 11:17 PM, Igor Korot wrote:
On Sun, Jun 30, 2013 at 7:47 PM, Igor Tandetnik wrote:
On 6/30/2013 10:27 PM, Igor Korot wrote:
1. I'm trying to minimize the number of requests I'm doing to the DB. What
I need is a way to count the number of rows that the query return to me
prior to
On 1 Jul 2013, at 4:13am, Igor Korot wrote:
> Well I will use another statement variable as in the sample code.
> My questions was: if I call delete on the record that was just retrieved in
> another query will this delete affects it?
I can’t say a definite 'yes’ because it depends on all sorts
On 6/30/2013 11:13 PM, Igor Korot wrote:
Well I will use another statement variable as in the sample code.
My questions was: if I call delete on the record that was just retrieved in
another query will this delete affects it?
If you change data that a live SELECT statement is iterating over, th
On Sun, Jun 30, 2013 at 7:47 PM, Igor Tandetnik wrote:
> On 6/30/2013 10:27 PM, Igor Korot wrote:
>
>> 1. I'm trying to minimize the number of requests I'm doing to the DB. What
>> I need is a way to count the number of rows that the query return to me
>> prior to going thru the "sqlite3_step()".
Simon,
On Sun, Jun 30, 2013 at 7:41 PM, Simon Slavin wrote:
>
> On 1 Jul 2013, at 3:27am, Igor Korot wrote:
>
> > 1. I'm trying to minimize the number of requests I'm doing to the DB.
> What
> > I need is a way to count the number of rows that the query return to me
> > prior to going thru the
On 6/30/2013 10:27 PM, Igor Korot wrote:
1. I'm trying to minimize the number of requests I'm doing to the DB. What
I need is a way to count the number of rows that the query return to me
prior to going thru the "sqlite3_step()".
If this number is 0, I want to skip the processing and just return.
On 1 Jul 2013, at 3:27am, Igor Korot wrote:
> 1. I'm trying to minimize the number of requests I'm doing to the DB. What
> I need is a way to count the number of rows that the query return to me
> prior to going thru the "sqlite3_step()".
Sorry, not possible. SQLite does not process the entire
Hi, ALL,
1. I'm trying to minimize the number of requests I'm doing to the DB. What
I need is a way to count the number of rows that the query return to me
prior to going thru the "sqlite3_step()".
If this number is 0, I want to skip the processing and just return. It's
not an error situation, it j
43 matches
Mail list logo
