Модератор: kdv
Код: Выделить всё
towns_write.StartTransaction;
DS_towns.append;
<..........>
try DS_towns.Post;
except DS_towns.Cancel;
end;
try towns_write.Commit;
except towns_write.Rollback;
end
Зависит от того, что ещё происходит между starttransaction и именно этим post. В смысле делаются ли ещё изменения в базе кроме этого post и если делаются, то следует ли их сохранять без этого изменения. А ещё от того, требуется ли вообще коммитить изменения каждой записи или можно пачкой. Post посылает изменения записи на сервер, что приводит к появлению новой версии записи, которую по чтению пока никто не видит, но которая блокирует попытки изменения этой записи другими транзакциями, если они read_commited до нашего коммита, если concurrency до их рестарта. По коммиту все _выполненные_ в рамках транзакции изменения становятся актуальными. Именно выполненные, а _не выполненные_ не становятся. Независимо от того, не делали их вообще или они обломились. То есть, в сценарииmaker писал(а):как будет правильней
Код: Выделить всё
towns_write.StartTransaction; DS_towns.append; <..........> try DS_towns.Post; except DS_towns.Cancel; end; try towns_write.Commit; except towns_write.Rollback; end
или может второй блок try вставить сразу после post'a
или может ни то ни другое неправильно...
[/code]
Код: Выделить всё
towns_write.StartTransaction;
try
DS_towns.append;
<..........>
DS_towns.Post;
except
on ...
DS_towns.Cancel;
end;
towns_write.Commit;
Код: Выделить всё
towns_write.StartTransaction;
try
DS_towns.append;
<..........>
DS_towns.Post;
towns_write.Commit;
except
on ...
begin
DS_towns.Cancel;
...
towns_write.Rollback;
end;
Дык потому всё больше и прикалываюсь. Или под настроение разжёвываю какой-нибудь абсолютный примитив, раскрывая вокруг него горизонты, типа думать учуkdv писал(а):Merlin, заносит тебя иногда...
А как пытаюсь всерьёз что-то на среднем уровне изложить, так и несёт - втиснуть всего Дейта с Грабером в одну ёмкую толстовскую фразу Если это update одной записи, то почему же не будет-то? Как раз и будет, причём без лишних роллбаков. Что получилось - закоммитит, что нет - отпустит транзакцию.kdv писал(а):
если все это написано именно так как выглядит, то работать не будет, потому что:
1. первый exception будет съеден первым except. Поэтому всегда будет вызываться commit.
Топорно конечно, но это дело его личного вкуса. Когда захочет - научится и конфликт обрабатывать и при настоящих неприятностях показывать причину и всё не теряя буфера ввода. Правда на одном гриде этого в общем случае не сделаешь, тут малость поболе потрудиться надо. Но это меня уже опять понеслоkdv писал(а): 2. DS_towns.Cancel не "отменяет" ввод записи. См. хелп. То есть, конечно, отменяет, но на уровне "ввода клиента". То есть, таким способом рубить клиенту ввод новой записи - извините. По любой ошибке тут же сразу хрясь - и DataSet в предыдущий вид возвращать?
И ещё при выполнении DDL, где основную работу сервер делает именно на коммите, а при выполнении операторов, грубо говоря, берёт для этого данные себе на заметку. Хотя ему об этом рано пожалуйkdv писал(а): 3. Как сказал Merlin, commit может выдать ошибку только если сервер сдох или соединение оборвано (еще на savepoints). То есть, когда уже собственно, поздно делать commit.
isql по умолчанию работает в autocommit DDL, по-моему Хвастунов и др. в конце концов тоже к этому пришли. А "Как сказал Merlin" - это звучит 
kdv писал(а): Так что, я бы написал (если добавление записи автоматизировано, а так конечно если это интерактивный ввод пользователя, то так не пишут)
Код: Выделить всё
towns_write.StartTransaction; try DS_towns.append; <..........> DS_towns.Post; except on ... DS_towns.Cancel; end; towns_write.Commit;
Но в этом случае уже вообще всё по фигу, IBX при обрыве уходит в штопор, как известно, навсегда.