SQLite last_insert_rowid()

Mr. Q · 10.03.2010

пытаюсь в .net через коннектор достать ID последней обработанной строки. возвращает 0.
в sqlite експерт всё нормально, после insert, возвращает правильный ID.

делаю то же самое в студии:
SELECT last_insert_rowid() as id - возвращает 0 в
int id = (int)reader["id"];

не знаю даже, что может помочь, разве что забить и мускул заюзать.

может быть, не стоит соединение закрывать после инсерта?

eugene_kr · 11.03.2010

Mr. Q сказав(ла):
skiped
может быть, не стоит соединение закрывать после инсерта?

Оно самое. Представь, что есть два пользователя, которые почти одновременно выполняют insert, но по какой-то причине пользователь выполнивший insert первым выполнит SELECT last_insert_rowid() вторым (insert@connection1, insert@connection2, select@connection2, select@connection1). Чей rowid он получит? Правильно - тот, который соответствует последнему insert'у в его собственном соединении.
В документации так и

Тільки зареєстровані користувачі бачать весь контент у цьому розділі

.
BTW функции, которые возвращают "внутреннюю" информацию БД (такую как последний ID вставленной строки, состояния различных счётчиков и т.д.) имеют определённую для них "область видимости изменений данных", которая, обычно, указывается в документации. В данном случае область видимости - текущее соединение. В других случаях "видимость" функции может быть на уровне текущей процедуры/функции/триггера/всей БД или как-то иначе.

lugal · 11.03.2010

eugene_kr сказав(ла):
Оно самое. Представь, что есть два пользователя, которые почти одновременно выполняют insert, но по какой-то причине пользователь выполнивший insert первым выполнит SELECT last_insert_rowid() вторым (insert@connection1, insert@connection2, select@connection2, select@connection1). Чей rowid он получит? Правильно - тот, который соответствует последнему insert'у в его собственном соединении.
В документации так и
Тільки зареєстровані користувачі бачать весь контент у цьому розділі
.
BTW функции, которые возвращают "внутреннюю" информацию БД (такую как последний ID вставленной строки, состояния различных счётчиков и т.д.) имеют определённую для них "область видимости изменений данных", которая, обычно, указывается в документации. В данном случае область видимости - текущее соединение. В других случаях "видимость" функции может быть на уровне текущей процедуры/функции/триггера/всей БД или как-то иначе.

Именно так и есть

Вот только про два пользователя с инсертами одновременно ты загнул - сулайт база - обычный файл и если он уже открыт на запись, тобишь есть коннект, второго коннекта небудит физически, нуникак.

2ТС а зачем дял СКУЛайта закрывать конект? Это ж нераспределенная БД, законектился и держи его хоть до утра.

eugene_kr · 11.03.2010

Обычно, побуждение закрывать соединение возникает либо из-за "экономии" ресурсов, либо из-за наличия нескольких рабочих потоков (процессов), так как писать в эту базу может только один поток, а читать может несколько. В последнем случае нужно в каждом потоке открыть соединение, выполнить модификацию данных, вычитать "результат" и произвести другую деятельность, после чего закрыть соединение. Таким образом, в теории, можно организовать работу нескольких потоков для работы с данными этой базы. Естественно в этом случае библиотека работы с БД должна быть потоко(процессо)безопасной.

lugal · 11.03.2010

eugene_kr сказав(ла):
Обычно, побуждение закрывать соединение возникает либо из-за "экономии" ресурсов, либо из-за наличия нескольких рабочих потоков (процессов), так как писать в эту базу может только один поток, а читать может несколько. В последнем случае нужно в каждом потоке открыть соединение, выполнить модификацию данных, вычитать "результат" и произвести другую деятельность, после чего закрыть соединение. Таким образом, в теории, можно организовать работу нескольких потоков для работы с данными этой базы. Естественно в этом случае библиотека работы с БД должна быть потоко(процессо)безопасной.

Нет, канечно такой механизм имеет право жить, однако оправдано ли это с точки зрения перформанса на открытие базы? ИМХО, оптимально в этом случае написать потокобезопасный враппер либо с блокировками на запись либо с обычным фолсом на запрос начала записи.

zavyalov · 11.03.2010

с SQLite дела не имел. В мускуле:

Тільки зареєстровані користувачі бачать весь контент у цьому розділі

все работает

eyeland · 11.03.2010

специалисты лол

разрабы sqlite вкурсе насчет блокировок, такчто можете смело открывать и модифицировать одну базу со всех потоков одновременно, sqlite потокобезопасен.

lugal · 12.03.2010

eyeland сказав(ла):
специалисты лол

разрабы sqlite вкурсе насчет блокировок, такчто можете смело открывать и модифицировать одну базу со всех потоков одновременно, sqlite потокобезопасен.

Колега, при попытке второго открытия на запись насколько мне помнитсо коннект просто обваливаеться, а постоянно ананировать базу на предмет освобождения тоже как то не гуд.

eyeland · 12.03.2010

lugal сказав(ла):
Колега, при попытке второго открытия на запись насколько мне помнитсо коннект просто обваливаеться, а постоянно ананировать базу на предмет освобождения тоже как то не гуд.

Плохо вам помнится. Ничего не обваливается, все отлично работает. Очевидно Вы что-то делаете не так.

Mr. Q · 14.03.2010

>>Оно самое.

спс, значит, я правильно думал.
А вообще, проблема решилась переходом на MySQL.

всем спасибо.