Здравствуйте, dave_2, Вы писали:

_>Возьмем для примера простейшую таблицу:

_>

_>CREATE TABLE tbl(key INTEGER PRIMARY KEY, cap TEXT NOT NULL);
_>

_>Если вставить новую запись с полем cap='AAA' (INSERT), удалить ее (DELETE)
_>и вставить новую (INSERT) с cap='BBB'.
_>То по крайней мере в sqlite запись с cap='AAA' и c cap='BBB'
_>будут иметь одинаковый "key" (имеется ввиду удаленная запись с cap='AAA'
_>имела скажем key=1, и новая запись тоже будет иметь key=1).

_>Я разрабатываю приложение, которое должно позволить
_>открывать одну и ту же запись в разных независимых окнах (вернее множество
_>записей пересечение которые может быть не нулевое, но для упрощение ограничимся
_>одной записью).

_>И вот допустим мы прочитали какую-то запись из таблицы,
_>превратили ее в объект,и открыли этот объект в нескольких окнах.
_>В одном окне мы нажали кнопку удалить, потом создали новую запись,
_>в это время у нас все еще открыто третье окно в котором данные уже
_>удаленной записи, допустим мы в нем что-то меняем и нажимаем сохранить,
_>и получится ерунда какая-то, если использовать "key" как уникальный
_>идентификатор объекта базы.

_>Что в таким случаях делают, вводят типа "кэш" между классами отвечающими
_>за работу с базой и программой, и все GUI работающее с базой подписываются
_>на события "кэша" и если в одном окне объект удаляется, то "кэш" извещает
_>окна что такого объекта нет?

С точки зрения бд тут всё ок — все сущности имеют уникальный первичный ключ. Проблема возникает от того, что клиенты работают с разными версиями данных. Решения: использовать транзакции, выбрать натуральный уникальный или первичный ключ, перенастроить что то в sqllite.

Здравствуйте, dave_2, Вы писали:

_>Возьмем для примера простейшую таблицу:

_>

_>CREATE TABLE tbl(key INTEGER PRIMARY KEY, cap TEXT NOT NULL);
_>

_>Если вставить новую запись с полем cap='AAA' (INSERT), удалить ее (DELETE)
_>и вставить новую (INSERT) с cap='BBB'.
_>То по крайней мере в sqlite запись с cap='AAA' и c cap='BBB'
_>будут иметь одинаковый "key" (имеется ввиду удаленная запись с cap='AAA'
_>имела скажем key=1, и новая запись тоже будет иметь key=1).

_>Я разрабатываю приложение, которое должно позволить
_>открывать одну и ту же запись в разных независимых окнах (вернее множество
_>записей пересечение которые может быть не нулевое, но для упрощение ограничимся
_>одной записью).

_>И вот допустим мы прочитали какую-то запись из таблицы,
_>превратили ее в объект,и открыли этот объект в нескольких окнах.
_>В одном окне мы нажали кнопку удалить, потом создали новую запись,
_>в это время у нас все еще открыто третье окно в котором данные уже
_>удаленной записи, допустим мы в нем что-то меняем и нажимаем сохранить,
_>и получится ерунда какая-то, если использовать "key" как уникальный
_>идентификатор объекта базы.

_>Что в таким случаях делают, вводят типа "кэш" между классами отвечающими
_>за работу с базой и программой, и все GUI работающее с базой подписываются
_>на события "кэша" и если в одном окне объект удаляется, то "кэш" извещает
_>окна что такого объекта нет?

С точки зрения бд тут всё ок — все сущности имеют уникальный первичный ключ. Проблема возникает от того, что клиенты работают с разными версиями данных. Решения: использовать транзакции, выбрать натуральный уникальный или первичный ключ, перенастроить что то в sqllite, что бы первичный ключ повторно не использовался бы.