On 8 Nov 2010, at 9:27pm, Stephen Chrzanowski wrote: > 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.
And naturally, since you are reading the row and it was retrieved in 'B' order, it is vital that the contents of the field is 'B'. Otherwise your code will not find the data in the order it has asked for it. > 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. So you require two copies of the data: one which is the data as it was when you started the SELECT command and another will all the updates that have taken place since then, until _finalize() is called. This means that the SELECT command must reserve enough memory for the entire results of the SELECT command, and copy all the data into it to process the initial SELECT command. So if I had a table which took 5 Gig of disk space and did a "SELECT * FROM myTable" my application would suddenly need to reserve 5 Gig of memory to store the results. This would make every SELECT very slow and use a lot of memory, useless on platforms which need to respond to button-presses in realtime or have limited memory. So I can understand why SQLite doesn't allow it. You can do this yourself, of course: perform the entire SELECT and store the results in one or more variables, then use the contents of those variables to decide which UPDATE commands to do. Or you can just use the UPDATE command with a WHERE clause, which does both commands in one go and is far more efficient. Simon. _______________________________________________ sqlite-users mailing list sqlite-users@sqlite.org http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
