|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Ребята, я в интербейзе не спец, просто досталось приложение, в котором после каждого селекта из базы стоит соммит. Зачем это так сделано? Сам работаю под Oracle, и приложение это тоже есть под оракл, так вот там тоже такая же песня - MainSQL.Open; Connection.Commit; Для работы с ораклом такая конструкция явно излишня, так может это рудимент остался от переноса из под IB ? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 11:40 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
По мойму это не совсем правильно.... комит обычно после группы операций... если иного не требует логика... скажем при больших вливках я делаю комит не чаще чем через 10 000 записей.... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 12:12 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Вообще-то commit используется после проведения изменений в базе (DELETE, UPDATE.....). А после получения данных (SELECT) он не нужен. Я тоже удивлЁн, зачем он там!? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 12:16 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Так вот в чем и вопрос - требует ли интербейз коммита после обычного селекта ? Или это была фишка разработчика ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 12:17 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Скорее глюк разработчика и тем более что после КАЖДОЙ записи. В принципе для селекта (если это не из процедуры) поровну комит будет или откат... но вот после каждого это делать не стоит всеж... ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 12:22 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Вопрос в тему, у меня в хранимой процедуре стоит инсерт и апдэйт. Вот я делаю селект * фром хп(:п0,:п1) а потом коммит. Потому что соммит в хп мне сделать не удается :-) так вот вопрос, хранимая процедура выполняется в тойже транзакции откуда вызывается? ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 12:56 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Если прога написана с использованием BDE, то там обычно кажется стоит Autocommit (точнее транзакцию нужно начинать явно самому), и коммит после select'а не нужен. (нет активной транзакции). Если же програ пользует что-то типа IBX то после select'а автоматически начинается транзакция. (это например хорошо видно в консоли IBConsole) Человек скорее всего делает коммит, чтобы не растягивать транзакции и избежать лишних блокировок, так как если другой юзер будет менять эти же данные, то скорее всего будут проблемы. Я когда юзал IBX тоже всегда так делал, это было первое, с чем я столкнулся когда переползал с BDE. Такое ощущение, что каждый IB Select аналогичен Oracle Select .. for update Так что я думаю что для Oracle этого делать не нужно, по крайней мере я никогда не делаю и все работает. ... |
|||
:
Нравится:
Не нравится:
|
|||
19.03.2003, 13:15 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
Speaker select блокировок не наклыдывает, если ему принудительно не сказать! ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2003, 03:04 |
|
Commit после SELECT
|
|||
---|---|---|---|
#18+
необходимость коммита после селект зависит от уровня изоляции и используемой версии сервера. 1) Если уровень изоляции SNAPSHOT и выше, то без коммита и перезапуска транзакции вы просто не увидите результатов действий соседних транзакций. Для read commited это не так важно, но лучше сразу писать универсальное решение, не так ли?. 2) Для версий серверов ниже ИБ6.5 и FB7 только читающая транзакция read commited, у которой стоит write в параметрах транзакции, удерживала версии записей и нагружала сервер! Поэтому коммит там жизненно был необходим. Для современных версий можно выставить для читающей транзакции параметр read и без перезапуска ей пользоваться. WBR, Alexey ... |
|||
:
Нравится:
Не нравится:
|
|||
20.03.2003, 11:24 |
|
|
start [/forum/topic.php?fid=40&fpage=524&tid=1580746]: |
0ms |
get settings: |
8ms |
get forum list: |
10ms |
check forum access: |
3ms |
check topic access: |
3ms |
track hit: |
111ms |
get topic data: |
9ms |
get forum data: |
2ms |
get page messages: |
40ms |
get tp. blocked users: |
1ms |
others: | 14ms |
total: | 201ms |
0 / 0 |