2000 Ошибки с транзакцией

← →
KAA (2002-08-16 11:51) [0]

При написании программы периодически допускаешь ошибки, в частности можно где-то не закрыть транзакцию. В результате клиентские приложения просто подвисают, пока не закроют подвисшего клиента. Но это блокирует работу и остальных клинетов, работающих с этой таблицей. А этих клиентов может быть штук 50, и сидят они по всему зданию.

Есть процедуры sp_lock и sp_who, с помошью которых по идее можно понять где и с чем произошла ошибка. Но как разобрать выдаваемую этими процедурами информацию я не знаю. Подскажите, что означают эти результаты.

← →
KAA (2002-08-16 11:51) [1]

51 4 0 0 DB S GRANT
53 7 0 0 DB S GRANT
54 4 0 0 DB S GRANT
55 7 0 0 DB S GRANT
56 7 0 0 DB S GRANT
57 7 0 0 DB S GRANT
58 7 0 0 DB S GRANT
59 7 0 0 DB S GRANT
60 7 0 0 DB S GRANT
61 7 0 0 DB S GRANT
62 7 0 0 DB S GRANT
63 7 0 0 DB S GRANT
64 7 0 0 DB S GRANT
65 7 0 0 DB S GRANT
66 7 0 0 DB S GRANT
67 7 0 0 DB S GRANT
67 1 85575343 0 TAB IS GRANT
68 7 312388182 0 TAB IX GRANT
68 7 1727345218 0 TAB IX GRANT
68 7 1727345218 12 KEY (4e001520a208) X GRANT
68 7 480720765 3 PAG 1:3642 IX GRANT
68 7 740197687 1 KEY (130092d8179c) X GRANT
68 7 1529772507 1 KEY (7e002223df56) X GRANT
68 7 740197687 0 TAB IX GRANT
68 7 1643868923 6 KEY (e1000b7f57de) X GRANT
68 7 1529772507 1 PAG 1:2483 IX GRANT
68 7 312388182 1 PAG 1:2469 IX GRANT
68 7 1727345218 13 PAG 1:2468 IX GRANT
68 7 633769315 1 KEY (2e00d992949f) X GRANT
68 7 633769315 1 PAG 1:2526 IX GRANT
68 7 1643868923 0 TAB IX GRANT
68 7 89767377 1 KEY (0300d2dc2e97) X GRANT
68 7 312388182 3 PAG 1:3699 IX GRANT
68 7 89767377 0 TAB IX GRANT
68 7 1727345218 14 PAG 1:3702 IX GRANT
68 7 480720765 2 PAG 1:3689 IX GRANT
68 7 633769315 17 KEY (360019f18248) X GRANT
68 7 480720765 0 TAB IX GRANT
68 7 959342482 1 PAG 1:2693 IX GRANT
68 7 1529772507 16 KEY (860056332b67) X GRANT
68 7 1529772507 15 KEY (860056332b67) X GRANT
68 7 959342482 1 KEY (8e00374934d4) X GRANT
68 7 959342482 1 KEY (8d00d9e681c6) X GRANT
68 7 459864705 1 PAG 1:2801 IX GRANT
68 7 1643868923 8 PAG 1:2804 IX GRANT
68 7 1727345218 1 KEY (2900e647255b) X GRANT
68 7 1529772507 0 TAB IX GRANT
68 7 1643868923 4 KEY (ed0007cefd99) X GRANT
68 7 633769315 0 TAB IX GRANT
68 7 312388182 3 KEY (2800094753e8) X GRANT
68 7 480720765 3 KEY (b400f3893735) X GRANT
68 7 1727345218 14 KEY (9f0084df7c75) X GRANT
68 7 1643868923 3 KEY (260137a8cf6c) X GRANT
68 7 1529772507 15 PAG 1:2978 IX GRANT
68 7 633769315 14 KEY (ac002700b7f5) X GRANT
68 7 89767377 4 KEY (2c000b211edb) X GRANT
68 7 312388182 2 KEY (a3002687b622) X GRANT
68 7 1643868923 5 KEY (e8009468cd8e) X GRANT
68 7 0 0 DB S GRANT
68 7 1643868923 1 PAG 1:3089 IX GRANT
68 7 89767377 1 PAG 1:3088 IX GRANT
68 7 480720765 1 PAG 1:3090 IX GRANT
68 7 1727345218 13 KEY (8e004ce94887) X GRANT
68 7 959342482 0 TAB IX GRANT
68 7 959342482 14 KEY (a800a164297d) X GRANT
68 7 959342482 14 KEY (a7004fcb9c6f) X GRANT
68 7 1643868923 2 KEY (e500446af889) X GRANT
68 7 959342482 13 KEY (0b012774a2ac) X GRANT
68 7 1643868923 8 KEY (02017716fc4d) X GRANT
68 7 959342482 13 KEY (0c01c9db17be) X GRANT
68 7 633769315 16 KEY (3500c866d2ca) X GRANT
68 7 480720765 1 KEY (a800c99cfe26) X GRANT
68 7 89767377 5 KEY (e00064425948) X GRANT
68 7 1727345218 11 KEY (56001430307d) X GRANT
68 7 959342482 14 PAG 1:3272 IX GRANT
68 7 959342482 13 PAG 1:3270 IX GRANT
68 7 459864705 1 KEY (49005437a738) X GRANT
68 7 1529772507 16 PAG 1:3325 IX GRANT
68 7 633769315 18 KEY (3000d195d799) X GRANT
68 7 1727345218 11 PAG 1:3310 IX GRANT
68 7 89767377 5 PAG 1:3311 IX GRANT
68 7 633769315 15 KEY (53002af513cc) X GRANT
68 7 1727345218 12 PAG 1:3306 IX GRANT
68 7 459864705 0 TAB IX GRANT
68 7 1727345218 1 PAG 1:3356 IX GRANT
68 7 633769315 18 PAG 1:3347 IX GRANT
68 7 633769315 17 PAG 1:3345 IX GRANT
68 7 740197687 1 PAG 1:276 IX GRANT
68 7 633769315 16 PAG 1:3343 IX GRANT
68 7 633769315 15 PAG 1:3341 IX GRANT
68 7 633769315 14 PAG 1:3339 IX GRANT
68 7 1643868923 6 PAG 1:3373 IX GRANT
68 7 1643868923 5 PAG 1:3371 IX GRANT
68 7 1643868923 4 PAG 1:3369 IX GRANT
68 7 1643868923 3 PAG 1:3367 IX GRANT
68 7 1643868923 2 PAG 1:3365 IX GRANT
68 7 480720765 2 KEY (d1001061ce6a) X GRANT
68 7 312388182 2 PAG 1:3414 IX GRANT
68 7 89767377 4 PAG 1:3406 IX GRANT
68 7 1643868923 6 KEY (e90084b4ed3c) X GRANT
68 7 1643868923 1 KEY (dd0084717b1e) X GRANT
68 7 312388182 1 KEY (2500d8159548) X GRANT
69 7 0 0 DB S GRANT
70 7 0 0 DB S GRANT
71 7 0 0 DB S GRANT
71 7 740197687 1 PAG 1:276 IS GRANT
71 7 740197687 0 TAB IS GRANT
71 7 740197687 1 KEY (130092d8179c) S WAIT

← →
KAA (2002-08-16 11:51) [2]

← →
Fiend (2002-08-16 13:15) [3]

Совет:

Никогда не начинайте транзакцию с клиента. Т.е. Database.BeginTran, ну или как там точно метод называется ,не помню. Но многие так делают.

Если нужно сделать что то важное, что может привести к фатальным ошибкам, т.е. нужно быдет вернуть всё как было, Используйте лучше цельный батч, который будет начинаться с начала транзакции, а заканчиваться соответственно Commit. Лучше даже сделать всё это в ХП.

← →
wicked (2002-08-16 13:34) [4]

можно сделать просто - у Connection есть метод Execute, которому можно скормить
"rollback tran" (отменить)
или "while @@trancount > 0 commit tran" (сохранить всё)...

в общем - тебе решать...

← →
KAA (2002-08-18 13:23) [5]

У меня вся программа на хранимых процедурах. Внутри процедуры транзакция открывается и закрывается.
Просто были глюки, я так и не понял почему, когда не сработал откат транзакции, а выход из процедуры отработал. В результате клинит таблицы.
Меня интересует, что означает инфа, полученная с помошью команд sp_lock и sp_who? Как по ней мне узнать, на какой машине в сети произошел клин.

← →
vuk (2002-08-18 15:29) [6]

В BOL расписано все, что эти процедуры выдают.

Насчет незапуска транзакций на клиенте - не знаю, но сроду с этим никаких проблем не было. Вся работа с БД ведется исключительно через SP. Каждый вызов процедуры делается в отдельной транзакции, запускаемой с клиента. Транзакции непосредственно внутри SP не используются.
Вызов пелается через следующую процедуру (вариант для BDE):

function GetBDEDatabase(DataSet: TDBDataSet): TDatabase; begin result := Sessions.FindSession(DataSet.SessionName).FindDatabase(DataSet.DatabaseName); end; procedure ExecBDEStoredProc(Proc: TStoredProc); begin with GetBDEDatabase(Proc), Proc do try StartTransaction; ExecProc; Commit; Execute("while @@Trancount > 0 commit"); except Rollback; raise; end; end;

← →
KAA (2002-08-19 17:28) [7]

Вообщем есть проблема.
В хранимой процедуре открывается транзакция, из нее запускаются другие хранимые процедуры. Если запускаемая ХП вернула ошибочный результат, происходит откат транзакции и выход их ХП. Но откат почему-то не происходит. Перед ROLLBACK TRANSACTION и после, функция @@trancount показывает одно и то же количество открытых транзакций. Естественно в результате остаются открытые транзакции и клиента клинет.

← →
vuk (2002-08-19 17:48) [8]

Попробуйте наоборот - чтобы транзакция инициировалась на клиенте, а не на сервере. Откат в этом случае тоже делается на клиенте, а ошибка в случае неудачи поднимается из SP при помощи raiserror. И попробуйте обойтись без вложенных транзакций.

← →
KAA (2002-08-19 17:55) [9]

>vuk © (19.08.02 17:48)
У меня вся программа на ХП, клиент только запускает процедуры. В связи с этим иногда приходится запускать процедуры имеющие свои транзакции, получаются вложенные. Изменить структуру программы уже нельзя.
Вообще эта вся система работает нормально. Но за последнее время у меня уже вторая ошибка, когда не откатывается транзакция.

← →
vuk (2002-08-19 18:14) [10]

>У меня вся программа на ХП, клиент только запускает процедуры.
А у меня, думаете, по-другому? :o) Тоже все исключительно на SP. Методика управления транзакциями никак не связана с вынесением логики на сервер.

← →
KAA (2002-08-19 18:32) [11]

>vuk © (19.08.02 18:14)
Что значит не связана? Транзакция открывается и закрывается внутри одной хранимой процедуры. ХП - самостоятельный законченный модуль, который может использовать другие такие же модули (ХП). У клиента только одна функция работы с базой - запуск ХП, больше ничего.

← →
vuk (2002-08-19 19:01) [12]

>Транзакция открывается и закрывается внутри одной хранимой
>процедуры.
У нас подход несколько другой. Одна операция клиента - одна транзакция. Операция может быть сложной внутри(на сервере), но она не порождает вложенных транзакций.

>У клиента только одна функция работы с базой - запуск ХП, больше
>ничего.
Аналогичная ситуация, но каждый вызов процедуры на клиенте заворачивается в собственную транзакцию.

← →
KAA (2002-08-19 19:56) [13]

> vuk © (19.08.02 19:01)
Честно говоря мне не нравится этот способ работы с базой. Если клиента вдруг выключат, получится незакрытая транзакция?
Кроме того, я могу просо командой вызвать нужную ХП.

← →
vuk (2002-08-19 20:20) [14]

>Если клиента вдруг выключат, получится незакрытая транзакция?
Нет, не получится. По правилам все незакрытые транзакции откатываются, что есть правильно.

>Кроме того, я могу просо командой вызвать нужную ХП.
Что значит "командой"? У Вас клиенты сами могут явно любые процедуры вазывать? Если нет, то в чем преимущество? Транзакцию не надо в явном виде расписывать на клиенте? Ну, это дело техники. А транзакция в результате все равно у Вас на сервере стартует, только Вы контроля над ней не имеете. Зато получаем не очень-то нужное усложнение работы на стороне сервера (особенно если вспомнить, что rollback на любом уровне вложенности откатывает все транзакции вверх по стеку), поскольку нарушается хорошее правило атомарности транзакций.

← →
KAA (2002-08-19 20:34) [15]

>Что значит "командой"? У Вас клиенты сами могут явно любые процедуры вазывать?
Клиенты не могут, зато я могу. Представь что клиент не готов, а процедуру надо запустить. Делаешь EXEC из квери аналайзера и все.
Ведь написаним базы и клиента занимаются разные люди, а база первична.
Кроме того, одну и ту же процедуру могут использовать разные клиенты. И работа с базой не зависит от ошибок клиента. Клиент может только запустить ПОЛНОСТЬЮ ГОТОВЫЙ САМОСТОЯТЕЛЬНЫЙ МОДУЛЬ, сохраняется принцип модульности. Все что можно взвалить на сервер - взваливается.

>А транзакция в результате все равно у Вас на сервере стартует, только Вы контроля над ней не имеете.
А какой контроль нужен. Если внутри процедуры, выполняющей несколько действий, происходит ошибка, откатываются все действия. Это единственное назначение транзакции у меня.

← →
vuk (2002-08-19 21:08) [16]

>Делаешь EXEC из квери аналайзера и все.
То есть хотите сказать, что я не смогу запустить процедуру, в которой нет явной транзакции из QA? :o)
>Ведь написаним базы и клиента занимаются разные люди, а база
>первична.
Старт транзакции из процедуры - это не халва по рубль-двадцать. :o) Придется чуть ли не каждую строчку проверять - как она выполнилась, причем это к бизнес логике отношения иметь не будет. Разработкой базы тоже разные люди занимаются. А ну как кто от правил разработки отойдет... Порой лучше на клиенте одну строчку написать, чем на сервере десяток.

>Кроме того, одну и ту же процедуру могут использовать разные
>клиенты. И работа с базой не зависит от ошибок клиента.
Да на здоровье! У нас работа с базой тоже от ошибок клиента не зависит.

>Клиент может только запустить ПОЛНОСТЬЮ ГОТОВЫЙ САМОСТОЯТЕЛЬНЫЙ
>МОДУЛЬ, сохраняется принцип модульности.
Совершенно верно, и это не зависит от того, кто транзакцию стартует.

← →
KAA (2002-08-20 10:08) [17]

>То есть хотите сказать, что я не смогу запустить процедуру, в которой нет явной транзакции из QA? :o)
Запустить можно, но если она отработает неправильно, а танзакцию ручками поленишься открыть?

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

>Разработкой базы тоже разные люди занимаются. А ну как кто от правил разработки отойдет...
Пока я один базой занимаюсь, а если еще кто-нибудь, то пусть полностью следует заложенным правилам.

>Порой лучше на клиенте одну строчку написать, чем на сервере десяток.
Не знаю, мы обратным правилом пользуемся.
Сервер купим крутой, и вся производительность от него будет зависеть. А клиенты у нас работают и на p166.

← →
Alexandr (2002-08-20 10:14) [18]

после прочтения этой ветки меня чуть не вырвало на MSSQL.
Уж лучше я на Paradox буду писать.

Хотя щас уже очень давно пишу для Interbase.

← →
3JIA9I CyKA (2002-08-20 11:23) [19]

2Alexandr
Ну-ну 8)

Больших Вам творческих успехов.

← →
Alexandr (2002-08-20 11:40) [20]

взаимно

← →
KAA (2002-08-20 15:36) [21]

>Alexandr ©
А что собственно тебе не понравилось? Мне просто уже интересно.

Послушать вледельцев двух иномарок о том, как они обычно меняют проколатое колесо и сказать, лучше на лесопеде ездить буду. :)

← →
vuk (2002-08-20 19:20) [22]

to KAA:
>Запустить можно, но если она отработает неправильно, а
>танзакцию ручками поленишься открыть?
Ну это уже другой вопрос. Скорее психологический, а не технический. :o) Да и основной режим работы - явно не QA.

>Ну немало у меня проверок, зато они все в базе.
Ну так у нас тоже в базе.

>Сервер купим крутой, и вся производительность от него будет
>зависеть. А клиенты у нас работают и на p166.
Это все правильно, но опять же место старта транзакции не влияет на производительность.

На самом деле то, о чем мы здесь спорим очень сильно смахивает на войны остроконечников и тупоконечников. :o)

to Alexander:
Ну что Вам по этому поводу сказать... IB в некоторых применениях месьма даже не плох. У нас на нем сайт работает. И нормально рабтает. Но вот корпоративную ИС мы на нем не делаем и делать не будем. Однозначно. Рвотных же рефлексов не вызывает ни MSSQL ни IB.
IB и MS SQL разные по идеологии СУБД. MS SQL - блокировочник, а IB многоверсионник. И поэтому приемы работы с ними разные. И проблемы тоже. Да и масштабы.

← →
KAA (2002-08-20 19:59) [23]

>Ну это уже другой вопрос. Скорее психологический, а не технический. :o)
Скажем так, это стратегия. Один раз что-нибудь на клиента перенесешь, и все, это вскоре опять повторится.
А если изворачиваешься и делаешь все в ХП, просто исключена ситуация, что в клиенте будет ошибка. Присекать потенциальную ошибку, выбрав стратегию полностью исключающую ситуацию, в которой ошибка может возникнуть. Исключил возможность ошибки, и даже не думаешь о ней, о том что она может появиться. Мне кажется этот подход оправдывает себя. Особенно когда в базе уже сам черт голову сломит, ты просто знаешь что подобная ошибка появится не может.

>На самом деле то, о чем мы здесь спорим очень сильно смахивает на войны остроконечников и тупоконечников. :o)
Может быть, но иногда и из таких споров можно что-то любопытное вынести.

← →
vuk (2002-08-20 20:51) [24]

to KAA:
>Один раз что-нибудь на клиента перенесешь, и все, это вскоре
>опять повторится. А если изворачиваешься и делаешь все в ХП,
>просто исключена ситуация, что в клиенте будет ошибка.

Дак все ж в базе, я ж говорю... Кроме транзакций. И вся логика живет в базе от начала и до конца. Ошибка клиента (в нашем случае) может быть только в том, что в нем каким-то мистическим образом будет обойден явно прописанный commit. Если честно, я слабо представляю себе такую ситуацию. Если же в процессе выполнения процедуры клиент по какой-либо причине отваливается, то в результате получаем закономерный rollback. Что, опять же, правильно, поскольку это укладывается в логику работы - аварийно прерванная операция должна быть отменена. Забыть прописать commit явно не получится, т.к имеются соответствующие соглашения и имеются библиотечки, благодаря которым можно не отвлекаться на такие мелочи и созданы такие условия, что писать правильно проще и удобнее, чем писать неправильно.

>Особенно когда в базе уже сам черт голову сломит, ты просто
>знаешь что подобная ошибка появится не может.
И тот и другой подход являются приемлемыми, и позволяют не особо задумываться об ошибках. Поверьте, тот подход, который мы используем обкатан уже не на одном проекте и про незавершенные транзакции слыхом не слыхивали. А что до ноги черта, то в текущем проекте - несколько БД, больше сотни (ближе к 150) таблиц, больше 500 процедур и это далеко еще даже не середина проекта. Полет нормальный.

← →
KAA (2002-08-20 21:21) [25]

>Ошибка клиента (в нашем случае) может быть только в том, что в нем
>каким-то мистическим образом будет обойден явно прописанный commit.
Вот этотслучай и страшен. Если каким-то бразом программа проскачила момент закрытия транзакции и продолжает работать с открытой на законном основании транзакцией. И почему этот случай мистический? Мне кажется что нельзя расчитывать на идеальность клиента.
Кроме того, программа привязана к этому клиенту. Если потом придет какой-нибудь студент и начнет писать свой клиент.

← →
vuk (2002-08-20 21:35) [26]

>Вот этот случай и страшен.
Я код выше приводил. Ну не случается такой случай. Никак не хочет случаться.

>И почему этот случай мистический?
Ну тогда исходя из того кода что приведен, скажите как это может получитьтся.

>Если потом придет какой-нибудь студент и начнет писать свой
>клиент.
Студент не придет. А если и придет, то будет писать так как ему скажут. К тому же я уже сказал, что условия созданы такие, что писать не правильно - неудобно.
К примеру зачем городить огород и писать криво, если можно (в нашем случае) написать примерно такое:
ExecStoredProc(spWGE_AddItem, ["ge_id", "g_id"], [0, Ag_id ]);

И все будет правильно - все параметры подставятся и вызов завернется в транзакцию.

← →
KAA (2002-08-20 21:48) [27]

>Ну тогда исходя из того кода что приведен, скажите как это может получитьтся.
Ну а ситуация, что в программе произойдет глюк, она подвиснет или еще что?

Кроме того, а вруг кто-нибудь напишет другой клиент. Скажем для доступа по html.

>Студент не придет. А если и придет, то будет писать так как ему скажут.
Т.е. административные методы защиты. Мне кажется что технические средства предпочтительней административных.

>К тому же я уже сказал, что условия созданы такие, что писать не правильно - неудобно.
Да он не знает как писать, он пишет как умеет, а умеет плохо. (по себе сужу, сам таким был)
Получается технология хорошо, но за ней надо следить. Т.е. в другой организации может не быть таких условий и студент придет писать клиента.

← →
vuk (2002-08-20 22:19) [28]

>Ну а ситуация, что в программе произойдет глюк, она подвиснет
>или еще что?
Там две строчки:

ExecProc;
Commit;

1. Подвисаем до ухода commit на сервер (или отвалился connect) - снимаем программу - получаем rollback.
2. А подвиснуть во время commit - это надо умудриться... :o) Оно либо в базу уже ушло и значит подтвердило транзакцию либо см. случай 1.
3. Exception в этом блоке - rollback в except. Единственный вариант ошибки - в это время отвалился коннект и невозможно явно вызвать rollback, см. случай 1.

>Кроме того, а вруг кто-нибудь напишет другой клиент. Скажем для
>доступа по html.
Гм... Сама по себе идея HTML клиента мне мягко говоря не очень нравится. Хотя если read-only, то может быть. Но если уж на то пошло, то сам по себе, напрямую, такой клиент все равно в базу не пойдет, а будет реализован как набор server-side приложений. И приложения эти должны быть написаны правильно.

>Мне кажется что технические средства предпочтительней
>административных.
Это средства одного порядка. Просто они находятся в другом месте. Просто в Вашем случае это средство - правильно оформлять SP, а в нашем - правильно их вызывать. Опять же, никто не помешает тому же студенту начать криво писать SP. :o)

>Да он не знает как писать, он пишет как умеет, а умеет плохо.
Еще раз объясняю - если кто-то придет в коллектив, он будет обязан соблюдать корпоративные стандарты, в том числе и на правила вызова SP, поскольку разработка групповая.

← →
KAA (2002-08-21 09:27) [29]

>1. Подвисаем до ухода commit на сервер (или отвалился connect)
> - снимаем программу - получаем rollback.
А кто будет снимать программу?
Например я пишу программу для гостиницы, т.е. ее использовать будут 24 часа в сутки 7 дней в неделю. А мы (компьютерная служба) работаем 5 дней в неделю с 9 до 18. Ни горничные, ни кассиры не снимут подвисшую программу. Максимум минут через 20 они надумают перегрузить компьютер. Но в течении этого времени остальные не смогут работать.

>Гм... Сама по себе идея HTML клиента мне мягко говоря не очень нравится.

>Опять же, никто не помешает тому же студенту начать криво писать SP. :o)
Но если если студенту дадут писать только клиента, уже меньше шансов что глюк пропутит.
А вдруг начальству понравится?

>Еще раз объясняю - если кто-то придет в коллектив, он будет
> обязан соблюдать корпоративные стандарты, в том числе и на
> правила вызова SP, поскольку разработка групповая.
У вас все завязано на жестких внутренних правилах. Это подход типа: я ошибку не допущу, и тек то под моим руководством работают тоже не допустят, я проконтролирую. А если я уйду с этой работы, то проблемы базы - не мои проблемы.
(Я уже постучпл по дереву) вдруг у вас изменятся условя работы и все толковые люди разбегутся, а новечки не станут придерживаться ваших правил. А вот если начальник в свое время настоял бы на том, чтоб все делал сервер, горе писатели нового клиента меньше могли бы допустить ошибок.

← →
Jeer (2002-08-21 10:10) [30]

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

← →
KAA (2002-08-21 11:32) [31]

>Jeer © (21.08.02 10:10)
Да, но может быть один общий стандарт, или два независемых.
Если база может сама обеспечивать свою безопасность, то можно ослабить контроль за написанием клиента.
Тот же дотуп через html. Я в этом не разбираюсь, и как я буду контролировать что там написано? А вот написать хранимые процедуры, которые не дудут ему сделать лишнее, я могу.

← →
vuk (2002-08-21 12:50) [32]

>А кто будет снимать программу?
То есть если у Вас клиентская программа при выполнении операции с БД зависнет, то ее даже никто прибить не попытается? Или машину перезагрузить? Интересная программа... :o)

Кстати, Ваш подход, судя по наличию этой ветки, от такой ситуации не страхует не смотря ни на что. Поэтому я и говорю, что разницы особой между ними нет.

>А вдруг начальству понравится?
Начальству не нравится в первую очередь. Оно достаточно технически подковано, чтобы понимать, что HTML и web-browser не есть хорошее средство для построения полнофункционального клиента БД, несмотря на то, что это местами сейчас модно.

>Это подход типа: я ошибку не допущу
Ничем от Вашего не отличается, т.к. что-то все равно придется писать по правилам.

>А если я уйду с этой работы, то проблемы базы - не мои
>проблемы.
Нет. Хорошая разработка должна документироваться. Далеко не всегда это выполняется, но это способ избежать проблем в будущем.

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

>А вот если начальник в свое время настоял бы на том, чтоб все
>делал сервер,
Ничего бы не поменялось. А сервер все и так делает...

>Я в этом не разбираюсь, и как я буду контролировать что там
>написано?
Где "там"? В HTML? Так этим server-side приложение должно заниматься. В нем должны соблюдаться общие правила.

>А вот написать хранимые процедуры, которые не дудут ему сделать
>лишнее, я могу.
От криво написанного клиента все равно не застраховаться. К тому же Ваш подход для корректной работы тоже требует определенной формы вызова с клиентской стороны - без транзакции. Ибо иначе он ничем от нашего не отличается. При этом надо помнить, что самым распространенным подходом как раз и является явный старт транзакции на клиенте.

Так что, как я уже написал, это все войны остроконечников с тупоконечниками...

← →
KAA (2002-08-21 13:20) [33]

>То есть если у Вас клиентская программа при выполнении операции
>с БД зависнет, то ее даже никто прибить не попытается? Или
>машину перезагрузить? Интересная программа... :o)
У нас основная часть пользователей не умеют работать с компьютерами и не хотят уметь. Машину они перезапустят, но не сразу. Снять задачу они не додумаются.

>Кстати, Ваш подход, судя по наличию этой ветки, от такой
>ситуации не страхует не смотря ни на что. Поэтому я и говорю,
>что разницы особой между ними нет.
У меня ошибка в программе, с которой я борюсь. Пока я ее не уберу, программа рабочей не будет.

>Начальству не нравится в первую очередь. Оно достаточно
>технически подковано, чтобы понимать, что HTML и web-browser не
>есть хорошее средство для построения полнофункционального
>клиента БД
Это частный случай вашего предприятия.
У нас технически подкована только компьютерная служба, больше никого.

>Нет. Хорошая разработка должна документироваться.
Это не означает, что люди будут писать по этим правилам. Их надо заставить. А если некому будет?

>>или все толковые люди разбегутся
>Если начальство такое допускает, то это плохое начальство. Такому никакие транзакции не помогут.
Ну допустим повторится август 98го и контора не сможет хорошо платить?

>>Я в этом не разбираюсь, и как я буду контролировать что там аписано?
>Где "там"? В HTML? Так этим server-side приложение должно заниматься. В нем должны соблюдаться общие правила.
Как я заставлю людей соблюдать эти правила, если я не могу понять, что он там пишет?

>От криво написанного клиента все равно не застраховаться.
Застрахуюсь. Если клиент будет глючить, он будет глючить один и не блокировать базу.

>Так что, как я уже написал, это все войны остроконечников с тупоконечниками...
Да вообщем интересно пока.

← →
vuk (2002-08-21 13:56) [34]

>Их надо заставить. А если некому будет?
Так Вашим правилам тоже нужно следовать. Определенные требования к клиенту выдвигаются в обоих случаях, просто они разные. Почему и утверждаю - никакой разницы нет.

>Застрахуюсь.
Предположим, что есть такой код(схематично):

DB.StartTransaction;
try
Proc.ExecProc; <- здесь вызов Вашей процедуры
DB.Commit;
except
db.rollback;
raise;
end;

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

>Как я заставлю людей соблюдать эти правила, если я не могу
>понять, что он там пишет?
Ответственность за соблюдение правил лежит непосредственно на разработчике. Он либо их соблюдает и тогда софт вписывается в существующую инфраструктуру (как он их будет соблюдать - проблема разработчика), либо - нет. Если нет - по рогам ему! :o)

← →
KAA (2002-08-21 14:31) [35]

>Так Вашим правилам тоже нужно следовать.
Но им должны следовать писатели сервера.

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

>Предположим, что есть такой код(схематично):
А предположим что нету. Клиент пишется с нуля. Например на другом языке.

>Ответственность за соблюдение правил лежит непосредственно на
>разработчике. Он либо их соблюдает и тогда софт вписывается в
>существующую инфраструктуру (как он их будет соблюдать -
>проблема разработчика), либо - нет. Если нет - по рогам ему!
А мне не нужны виноватые в том, что база подвисла. Мне нужно чтоб она не подвисла.

У нас всеж разные подходы.
В вашем случае, база и клиент - одна задача. А у меня это две задачи, просто они нужны обе. Но у меня в базе есть очень много вещей, коорые клиент не использует, но может в любой момент использовать. А могу я использовать из командной строки.

← →
vuk (2002-08-21 14:43) [36]

>А предположим что нету. Клиент пишется с нуля. Например на
>другом языке.
Ну елы-палы... :-(
Вы так и не поняли о чем я. Я имею в виду ход действий на клиенте. При чем здесь язык-то?

>А мне не нужны виноватые в том, что база подвисла. Мне нужно
>чтоб она не подвисла.
Гм... При другой логике работы клиента - запросто. То есть Вы тоже завязываетесь на реализацию клиента.

← →
KAA (2002-08-21 15:09) [37]

>Вы так и не поняли о чем я. Я имею в виду ход действий на клиенте. При чем здесь язык-то?
А язык может вносить свои нюансы, из-за которых не получится такой ход действий.

Моя логика такая, если в клиенте ошибка, она должна максимум проявляться в работе с этим клиентом. Из-за нее не должна подвисать база. И нельзя закладываться на то, что клиент будет написан так и никак иначе.

>>А мне не нужны виноватые в том, что база подвисла. Мне нужно чтоб она не подвисла.
>Гм... При другой логике работы клиента - запросто. То есть Вы тоже завязываетесь на реализацию клиента.
Представьте что с базой работают два разных клиента, написанных двемя разными людьми. Мало того, у каждого клиента было много версий и на разных компьютерах стоят разные версии. Предположим в одной из версий одного из клиентов ошибка, которая еще и не всегда проявляется. Так вот она не должна мешать остальным.

← →
vuk (2002-08-21 15:25) [38]

>А язык может вносить свои нюансы, из-за которых не получится
>такой ход действий.
Транзакция - она и в Африке транзакция, и к языку программирования отношения не имеет.

>Так вот она не должна мешать остальным.
Так не получится же на все 100% это обеспечить. На все случаи жизни застраховаться не удастся.

← →
KAA (2002-08-21 15:33) [39]

>Транзакция - она и в Африке транзакция, и к языку программирования отношения не имеет.
Но кроме транзакции может потребоваться написать еще целый ряд команд. Вот там глюк и затаится.
Да и вообще, можно просто так взять и написать другую конструкцию. Неважно по какой причины, если такая ситуация возможна, значит рано или поздно она произойдет.

>Так не получится же на все 100% это обеспечить. На все случаи жизни застраховаться не удастся.
Клиент может запускать хранимые процедуры. Если ни одна из этих процедур не будет мешать другим, то и клиент уже ничего не сделает с базой.

← →
vuk (2002-08-21 15:42) [40]

>Но кроме транзакции может потребоваться написать еще целый ряд
>команд.
Елы-палы...
Я у Вас пытаюсь выяснить, что будет, если Вашу процедуру вызывать внутри транзакции... Вы уверены, что это не будет мешать другим процедурам? Меня сейчас в других конструкциях глюки не интересуют.

← →
KAA (2002-08-21 15:51) [41]

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

← →
vuk (2002-08-21 16:07) [42]

О! Так вот, ни в том ни в другом случае процедуры в базе друг другу мешать не будут. :o) С другой стороны неправильно написанный клиент может свести на нет все усилия.

← →
KAA (2002-08-21 16:21) [43]

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

← →
KAA (2002-08-21 16:29) [44]

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

← →
Desdechado (2002-08-21 16:57) [45]

Занимательная беседа ...
Плотник со столяром анализируют качество дров :)
А дрова-то не березовые, а из прессованного угля.

← →
vuk (2002-08-21 17:14) [46]

А я давно написал, что все это вроде войны остроконечников и тупоконечников - с какого конца яйцо разбивать. :o)

← →
KAA (2002-08-21 17:31) [47]

Самое что смешное, я могу привести веские доводы необходимости разбивания яйца как с одной, так и с другой стороны. :)

2000 Ошибки с транзакцией Найти похожие ветки