Hello Robert Simpson, >For the SQLite ADO.NET wrapper, I actually wrote two functions into the core >engine to help me retrieve key information. My requirements were a little >more complex than just getting rowid, but here's what I did to get me that >far at least: > >Given a sqlite_stmt pointer consisting of a SELECT on one or more tables, > 1. For each table, fetch the internal cursor for that table in the >statement > 2. For each cursor, fetch the rowid > >That was the API modification part. Caveats are that this information is >not always available. So if its not, I just return a failure indicator.
Thanks for backing me up on my problem. However, unlike you I am very reluctant to hack the SQLite because of the concerns you mentioned. I would love to see something similar to what you have done officially supported by SQLite. >The next part involved querying the schema of each table, looking up indexes >and finding the most logical primary key definitions for the table(s) involved >in the select, and compiling a side-by-side SELECT clause returning the user's >defined primary keys using a WHERE clause with the above fetched rowid's. For cell updates, SQLiteSpy would be happy to use the RowID index, which is auto-generated and always available. Hence a function like sqlite3_column_rowid() would just fill the gap perfectly. Let's see what the future brings ... Regards, Ralf PS: For anyone interested: The new SQLiteSpy with table cell editing is now available at http://www.yunqa.de/delphi/sqlitespy/ ----------------------------------------------------------------------------- To unsubscribe, send email to [EMAIL PROTECTED] -----------------------------------------------------------------------------
