As mentioned, don't use raw rowid, define a "my_id INTEGER PRIMARY KEY
AUTOINCREMENT". This currently acts as an alias to rowid, but if the
implementation changes in the future, it will continue to work as
documented. So things will be correct, but they might not be as
efficient as before.
Splitting the INSERT and SELECT isn't that bad. Prepare both
statements, then something like:
int rv;
while ((rv = sqlite3_step(select_stmt)) == SQLITE_ROW) {
for (int i = 0; i < sqlite3_bind_parameter_count(insert_stmt)) {
rv = sqlite3_bind_value(insert_stmt, i,
sqlite3_column_value(select_stmt, i));
if (rv != SQLITE_OK) Panic();
}
rv = sqlite3_step(insert_stmt);
if (rv != SQLITE_DONE) Panic();
Remember(sqlite3_last_insert_rowid(db));
rv = sqlite3_reset(insert_stmt);
if (rv != SQLITE_OK) Panic();
}
if (rv != SQLITE_DONE) Panic();
Shouldn't perform much different than the big statement.
-scott
On Thu, Jan 7, 2010 at 7:56 AM, Max Vlasov <max.vla...@gmail.com> wrote:
> Thanks for the answers. At the first place I wanted to use rowid to save
> space (since rowids always exist). After reading the replies I changed
> declaration of ID to the one without AUTOINCREMENT and manually fill the
> consecutive values starting current max(rowid)+1. So rowids still used but
> now they're under my full control.
>
> I have a query "INSERT ... SELECT" and after it performed it I have to to
>> store range of rowids (autoincrement) of the inserted rows. While max(rowid)
>> for right bound seems ok, assuming max(rowid)+1 for the left bound (before
>> the query) depends on the fact whether there were deletes from the table
>> before. If there were deletes, my estimation will differ from the actual
>> value. So is there a correct way to know the range of rowids in this case or
>> just to know for sure "expected" rowid in similar cases?
>>
>>
> _______________________________________________
> 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
