Получение последнего вставленного идентификатора - PullRequest
Новая
       7

Получение последнего вставленного идентификатора

3 голосов
/ 15 июня 2011

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

    Database.ExecuteNonQuery(query, parameters);

    //if another client/connection inserts a record at this time, 
    //could the line below return the incorrect row ID?
    int fileid = Convert.ToInt32(Database.Scalar("SELECT last_insert_rowid()"));
    return fileid;

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

Предположим, что есть два клиентских приложения, каждое из которых имеет свои собственные отдельные подключения к базе данных, которые в одно и то же время вызывают вышеуказанный метод на стороне сервера.Помня о том, что клиентские потоки работают параллельно и что SQLite может выполнять только одну операцию за один раз (или я так слышал), будет ли возможно для одного экземпляра клиента вернуть идентификатор строки записи, которая была вставленадругой экземпляр?

Наконец, есть ли лучший способ получить последний вставленный идентификатор строки?

Ответы [ 2 ]

6 голосов
/ 15 июня 2011

Если в это время другой клиент / соединение вставляет запись, может ли строка ниже вернуть неправильный идентификатор строки?

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

Помня о том, что клиентские потоки работают параллельно и что SQLite может одновременно выполнять только одну операцию, один клиент мог бы получитьидентификатор строки записи, которая была вставлена ​​другим клиентом?

Да, конечно.

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

, если вы еще этого не сделали, имейте для чтения модель блокировки файлов SQLite .

2 голосов
/ 26 августа 2011

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

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

...