I don't know how the code works, but logically speaking, if I'm at row B,
and I update row B to E, row B physically remains B but has its data content
changed to E.  From there on in, it should go on to C then D then F, etc.

Since the full rowset results already exist somewhere, it shouldn't show up
anywhere else down the line, simply because the updated or even new
recordset isn't part of the compiled result set list.

In other words, when I make a SELECT statement, the results that come back
would point to the physical locations of where the raw data exists, or,
return the data and stores it in memory, or however the mechanism works.
Updating should not affect what rows have been called up.

On Sun, Nov 7, 2010 at 9:16 PM, Simon Slavin <slav...@bigfraud.org> wrote:

>
> On 8 Nov 2010, at 2:02am, cricketfan wrote:
>
> > Simon, As per my understanding I am getting the result set and trying to
> > change values in the table based on what I read from the result set up to
> > that point. I see no reason why I should be stopped from updating the row
> I
> > have already read in the result set.
>
> Your update might change whether the row is in the result set.  Or it might
> change /where/ the row falls in the result set.  For instance, suppose you
> have the following rows:
>
> A
> B
> C
> D
> F
>
> You read as far as B, then decide to change the B to an E.  Now what should
> happen ?  Should that record appear again when you get past the D ?  But it
> might be a problem to include the same record twice.  How should SQL know
> what it should do ?  So SQL prevents you from making changes which effect an
> open SELECT.
>
> Simon.
> _______________________________________________
> sqlite-users mailing list
> sqlite-users@sqlite.org
> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
>
_______________________________________________
sqlite-users mailing list
sqlite-users@sqlite.org
http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users

Reply via email to