"It won't be too big..." famous last words. I think the rowid is probably safe for what you're trying to do, despite the well-intentioned advice others have given you against it.
Also, if you think the underlying data may change, then I'm not sure what good reading the whole table will give you... if the underlying data changes, row #28 the first time around may not be row #28 the second time around. Even if you use an ORDER BY clause, which you'll absolutely have to do if you go the read-whole-table route. What you might want to do is build a map between row number in your grid and rowid in the database... that way you aren't relying on the rowids being set a certain way, nor relying on the rowids being returned to your app in a particular order. -T On Thu, Feb 19, 2009 at 9:09 PM, His Nerdship <[email protected]> wrote: > > OK, thanks for the info. > I will just do what I said before, namely read the whole table (it won't be > too big) and extract the required row from the returned array. > The reason I wanted a row ID was that all the fields in the display grid can > be edited, so by the time I come to process it, any of them might have > changed from the original in the database so I can't use them in a WHERE > clause. > At least I know now.... > Thanks again > > > P Kishor-3 wrote: >> >> On Thu, Feb 19, 2009 at 6:54 PM, His Nerdship >> <[email protected]> wrote: >>> >>> Hi, >>> I am converting a program from Paradox (stop laughing, please) to SQLite. >>> Paradox has a useful feature where you can specify the actual index of a >>> row >>> in the table. This is handy when the table is displayed in a grid and >>> you >>> want the record corresponding to a row in that grid - you can just >>> specify >>> the index, say 28, of that grid row and it will get the record no 28 from >>> the table. It spares the need for a SELECT statement, and is a lot more >>> efficient. >>> As a SQLite newbie, the only way I can see to do this is to read the >>> whole >>> table with sqlite3_get_table() and then get the required row from the >>> returned array. This seems overkill when I just want a single record. >> >> There is the rowid, but I am not sure what you want to do... are you >> expecting a database table to be a linear list of entries? Generally >> one uses a spreadsheet for that kind of stuff. A SQL database doesn't >> have an internal concept of order. You specify a criteria and the db >> returns a SET of rows or records. You can constrain the SET by >> specifying criteria (the WHERE clause), and you can impose an order on >> the returned rows by specifying an ORDER clause. >> >> If you want just one specific row, just do a >> >> SELECT cols FROM table WHERE some_primary_key = ? >> >> If you don't want to specify and control your own primary key, you can >> use the rowid which is something the db uses internally for its own >> shenanigans. >> >> >>> Is there a more compact way of doing this? >>> Thanks in advance etc. >>> Sholto >> >> >> >> -- >> Puneet Kishor http://www.punkish.org/ >> Nelson Institute for Environmental Studies http://www.nelson.wisc.edu/ >> Open Source Geospatial Foundation (OSGeo) http://www.osgeo.org/ >> Sent from: Madison Wisconsin United States. >> _______________________________________________ >> sqlite-users mailing list >> [email protected] >> http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users >> >> > > -- > View this message in context: > http://www.nabble.com/Any-concept-of-row-number-in-SQLite--tp22112862p22113562.html > Sent from the SQLite mailing list archive at Nabble.com. > > _______________________________________________ > sqlite-users mailing list > [email protected] > http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users > _______________________________________________ sqlite-users mailing list [email protected] http://sqlite.org:8080/cgi-bin/mailman/listinfo/sqlite-users
