Identity

← →
DeadMeat © (2007-05-11 19:23) [0]

Доброе время.
Очередной вопрос от новичка.
Есть две таблицы. В обоих присутствует поле Code, типа int со "свойством" Identity (счетчик вообщем). Оно является primay key.
При добавлении записи в одну из таблиц, мне надо также добавить некоторые данные и во вторую, связав их этим самым полем. Т.е. во второй есть дополнительное поле, в котором указывается содержимое Code из первой.
Так вот вопрос.
У меня для добавления записи в первую таблицу, открывается диалог. В этом диалоге открывается второй, в котором юзер добавляет данные и во вторую таблицу. Вот как теперь мне записать во вторую таблицу, содержимое поля Code из первой? Ведь запись еще не закомитена в базу, а следовательно сервер еще не заполнил это поле.
Пока у меня вариант только один. При открытии первого диалога, сделать Append, Post и потом Edit у первой таблицы. Чтобы закомитить запись.
В случае если юзер нажмет Cancel в первом диалоге, стереть эту запись из таблицы.
Но сразу видется подводный камень. Если программа зависнет или нештатно закроется (сбой питания или еще чего), то в таблице останется пустая запись. Добавлять сервис, который будет за этим следить и "чистить" такие записи не очень хочется.
Может есть другой способ подобной "связки"? Может можно "вытащить" это поле не добавляя запись физически в таблицу?

← →
Anatoly Podgoretsky © (2007-05-11 19:33) [1]

> DeadMeat (11.05.2007 19:23:00) [0]

У тебя что пользователь оперирует номерами, вместо данных?

← →
Desdechado © (2007-05-11 19:39) [2]

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

← →
Johnmen © (2007-05-11 19:40) [3]

> Может можно "вытащить" это поле не добавляя запись физически
> в таблицу?

Нельзя, ибо нет вставки - нет наращивания автоинкримента.

← →
DeadMeat © (2007-05-11 20:47) [4]

> [1] Anatoly Podgoretsky © (11.05.07 19:33)

Не совсем так. Добавляя одну запись в первую таблицу, он дополнительно (во втором диалоге) добавляет записи во вторую. И их то и надо связать с первой таблицей.

> [2] Desdechado © (11.05.07 19:39)

Помню. Было. Сделал. Применил. Но вот именно кеширование в данном случае и не помогает. А вот конкретно в этом проверить транзакции как то не дотюкал, т.к. заменил их использование в этом месте на кеширование. Значится надо теперь совместить одно с другим. Спасибо. Чета торможу в последнее время.

> [3] Johnmen © (11.05.07 19:40)

Вот собсна в этом и проблема. Транзакции помогут в данном случае "эмулировать" эту вставку? Сейчас стало думаться, что помогут, но к сожалению пока проверить нет возможности.

← →
Johnmen © (2007-05-11 21:00) [5]

Транзакции ничего не "эмулируют". Они либо есть (когда мы работаем с БД), либо нет (когда пьём пиво, лежа на диване).
И проверять ничего не надо. А надо просто почитать основы...

← →
DeadMeat © (2007-05-14 08:32) [6]

Спасибо. Заработало.
Правда какието непонятки у меня с ними. У меня сейчас два проекта и я немного путаюсь между ними. Странная ситуация возникла в другом. Открыв транзакцию, сделав изменения, а потом закрыв (RollBack), изменения все равно сохраняются в базу (ACCESS). Вот и не пойму, что еще может сделать некий Commit. Потому как я его во всей программе не делаю ни в одном месте.

← →
Ega23 © (2007-05-14 09:57) [7]

Читайте про хранимые процедуры и Scope_Identity()

← →
ANB © (2007-05-14 12:32) [8]

> Открыв транзакцию, сделав изменения, а потом закрыв (RollBack),
> изменения все равно сохраняются в базу (ACCESS).

Аксесс начал поддерживать транзакции ?

← →
Desdechado © (2007-05-14 13:49) [9]

> Потому как я его во всей программе не делаю ни в одном месте.
Вообще-то есть и неявные транзакции, длиной в одну SQL-команду.
Если ты не открыл транзакцию явно, то стартует неявная транзакция.
И еще помни, что для разных подключений даже в одной программе транзакции разные (это к тому, что использование Query без Connection/Database ведет к неявному созданию новых подключений для каждого запроса). А некоторые подключения поддерживают и несколько одновременных транзакций.

← →
DeadMeat © (2007-05-14 14:23) [10]

> Ega23 © (14.05.07 09:57) [7]

Ок... Надо вообще хорошую книжку по этому делу найти. Что посоветуете?

> ANB © (14.05.07 12:32) [8]

Да шоб я знал. В инете порылся, вроде никто не говорит, что не поддерживает.

> Desdechado © (14.05.07 13:49) [9]

Транзакция была открыта явно. BeginTrans сделал. Изменил данные. Сделал RollBack. Изменения сохранились. Если я правильно понимаю, то внутри моей транзакции любые изменения должны быть контролируемыми. В том смысле, что если внутри моей транзакции будет открыта еще одна, то откатив мою, разве та (вложенная) не должна тоже откатится независимо от ее подтверждения?
К примеру:
BeginTrans
...BeginTrans
...CommitTrans
RollBackTrans
После всего этого (если я опять же правильно понял), по идее все (в таблицах) должно остаться как и было. Разве нет?

> BeginTrans
> ...BeginTrans
> ...CommitTrans
> RollBackTrans

Вложенные транзакции даже оракл не поддерживает. Разве что через извраты с автономной.

> Ок... Надо вообще хорошую книжку по этому делу найти. Что
> посоветуете?

Лучше Books OnLine ничего для MSSQL не видел.

> Транзакция была открыта явно.
Проверь еще раз, как выполняются запросы (через какие явно указанные соединения и явно указанные транзакции этих соединений).

> Ega23 © (14.05.07 14:36) [12]

Ну это даа... Почитываю как возникает необходимость.

> Desdechado © (14.05.07 15:19) [13]

Вот гдето через пару часов доберусь домой и там попробую с нуля проект накидать. Без всего лишнего.

Identity Найти похожие ветки