SQLite last_insert_rowid()

[Mr. Q]

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

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

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

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

 

[eugene_kr]

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

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

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

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

 

[lugal]

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

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

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

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

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

 

[eugene_kr]

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

 

[lugal]

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

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

 

[zavyalov]

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

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

все работает

 

[eyeland]

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

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

 

[lugal]

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

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

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

 

[eyeland]

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

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

 

[Mr. Q]

>>Оно самое.

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

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