про интерфейс
Есть объект:
OBJECT -+
|
+-PHONE
|
+-FAX
|
+-OTHER
Когда заполняешь форму, на ней нужно добавить и эти , зависимые элементы.
Но объекта ЕЩЕ НЕТ!! Я еще не делал INSERT. Следовательно еще не создался
счетчиком в базе его ID. И к чему привязывать эти , зависящие от него элементы ?
Я пошел путем .. (по В.И. Ленину ..)
Делаю пустую запись ради создания счетчиком ID.
И на нее начинаю цеплять PHONE, FAX. Пустую запись OBJECT замечают юзеры по сети и
уничтожают или модифицируют ее.
:(
SELECT GEN_ID(имя_генератора, 1) FROM RDB$DATABASE
Получаешь таким образом значение новое ID не вставляя запись, его и используешь для связей. Главное в INSERT потом не забудь его (ID) вставить, наряду с остальными полями.
Делаешь
SELECT GEN_ID(имя_генератора, 1) FROM RDB$DATABASE
Получаешь таким образом значение новое ID не вставляя запись, его и используешь для связей. Главное в INSERT потом не забудь его (ID) вставить, наряду с остальными полями.
Это хорошо, но таблицы связаны через внеший ключ.
Прийдется тригерами.
Это хорошо, но таблицы связаны через внеший ключ.
Прийдется тригерами.
А почему нельзя сначала сохранить запись в главной таблице, а потом уже в зависимых.
Все в одной транзакции, тогда никто не удалит запись из главной пока не завершится транзакция.
Я так обычно делаю:
1) SELECT GEN_ID(имя_генератора, 1) FROM RDB$DATABASE - даже если другой пользователь тут же вставить еще одну запись, он уже получит новое значение генератора, а это гарантированно наше
2) INSERT главная_таблица (ID, ...) VALUES (:NEW_ID, ...) - дальнейшие одновления или вставки в зависимые таблицы не вызовут ругани про внешний ключ. Если в параметрах транзакции приложения стоит read_commited, то никто ее не увидит, пока мы тут не закончим
3) INSERT или UPDATE связанных таблиц
4) COMMIT
А почему нельзя сначала сохранить запись в главной таблице, а потом уже в зависимых.
Все в одной транзакции, тогда никто не удалит запись из главной пока не завершится транзакция.
Не только нельзя, но можно и нужно. А чтобы не иметь лишнего геморроя, в компонентах работы с БД обычно предусмотрен режим CachedUpdates.
А почему нельзя сначала сохранить запись в главной таблице, а потом уже в зависимых.
Все в одной транзакции, тогда никто не удалит запись из главной пока не завершится транзакция.
Я так обычно делаю:
1) SELECT GEN_ID(имя_генератора, 1) FROM RDB$DATABASE - даже если другой пользователь тут же вставить еще одну запись, он уже получит новое значение генератора, а это гарантированно наше
2) INSERT главная_таблица (ID, ...) VALUES (:NEW_ID, ...) - дальнейшие одновления или вставки в зависимые таблицы не вызовут ругани про внешний ключ. Если в параметрах транзакции приложения стоит read_commited, то никто ее не увидит, пока мы тут не закончим
3) INSERT или UPDATE связанных таблиц
4) COMMIT
Замечательная вещь эта транзакция , как то до сих пор обходился. :)
--------------------------
Спасибо Николаю & Freeman