select ... for update vs. update ... set <column>=<column> / Informix

ReSQL.ru

Мобильная версия Контакт Правила FAQ Помощь

Гость

Войти | Регистрация | Профиль | Очистить

Новые сообщения | Избранное

Форумы | Пользователи | Статистика | Мод. лог | Поиск

Цитировать

Написать

Автор*:

Ввести пароль для входа

Тема*:

Сообщение

Данное сообщение тематическое

Сообщение содержит картинки или видео 18+

Автор:

ВНИМАНИЕ! На данном подфоруме действуют строгие правила. Удостоверьтесь, что ваше сообщение соответствует им!

Форум или тема закрыты для гостей. Необходима авторизация!

Загрузить последнюю сохраненную версию

Вложение:

Вставить как галерею

Максимальный размер вложений: 4,0 МБ, аудио/видео: 8,0 МБ. Картинки большего размера ужимаются, если возможно.

Введите код, изображенный на картинке. Если код нечитаемый, кликните картинку, чтобы загрузить другой вариант.

Отправляя сообщение, я выражаю свое согласие с правилами форума и принимаю пользовательское соглашение.

Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр

Форумы / Informix [игнор отключен] [закрыт для гостей] / select ... for update vs. update ... set <column>=<column>

22 сообщений из 22, страница 1 из 1

select ... for update vs. update ... set <column>=<column>

#33593807

softic

Гость

Коллеги, есть вопрос по блокировкам:
как во время транзакции наиболее эффективно заблокировать строку от записи?

нужна блокировка изменения/удаления записи, при этом чтение должно работать нормально (хотя всё равно почти весь код в dirty read).

как я понимаю, для этой цели должно служить выражение

Код: plaintext

select ... for update

, однако в SPL оно приводит к изменяемой блокировке.

в результате приходится выполнять выражения типа

Код: plaintext

update ... set <column>=<column>

...

Рейтинг:

0 / 0

10.03.2006, 19:24

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593845

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

softicКоллеги, есть вопрос по блокировкам:
как во время транзакции наиболее эффективно заблокировать строку от записи?

нужна блокировка изменения/удаления записи, при этом чтение должно работать нормально (хотя всё равно почти весь код в dirty read).

как я понимаю, для этой цели должно служить выражение

Код: plaintext

select ... for update

, однако в SPL оно приводит к изменяемой блокировке.

в результате приходится выполнять выражения типа

Код: plaintext

update ... set <column>=<column>

- мне они не очень нравятся, так как статистика использования таблиц нарушается (сильно растут isrewrite) и, наверное, это не самый оптимальный вариант по производительности.

есть ли какой-нибудь другой вариант блокировки строк от изменений?

заранее большое спасибо! :)

set isolation
Using the Cursor Stability Option
Use the Cursor Stability option to place a shared lock on the fetched row,
which is released when you fetch another row or close the cursor. Another
process can also place a shared lock on the same row, but no process can
acquire an exclusive lock to modify data in the row. Such row stability is
important when the program updates another table based on the data it reads
from the row.
If you set the isolation level to Cursor Stability, but you are not using a transaction,
the Cursor Stability isolation level acts like the Committed Read
isolation level.
Using the Repeatable Read Option

Using the Repeatable Read Option
Use the Repeatable Read option to place a shared lock on every row that is
selected during the transaction. Another process can also place a shared lock
on a selected row, but no other process can modify any selected row during
your transaction or insert a row that meets the search criteria of your query
during your transaction. If you repeat the query during the transaction, you
reread the same information. The shared locks are released only when the
transaction commits or rolls back. Repeatable Read is the default isolation
level in an ANSI-compliant database.
Repeatable Read isolation places the largest number of locks and holds them
the longest. Therefore, it is the level that reduces concurrency the most.

...

Рейтинг:

0 / 0

10.03.2006, 19:48

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593855

softic

Гость

onstat- set isolation ...
тогда надо менять уровень изоляции - а без этого никак?

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

...

Рейтинг:

0 / 0

10.03.2006, 19:58

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593859

vasilis

Участник

Откуда: Украина, Киев

Сообщения: 2 212

Рейтинг: 0 / 0

softicнужна блокировка изменения/удаления записи, при этом чтение должно работать нормально (хотя всё равно почти весь код в dirty read).
есть ли какой-нибудь другой вариант блокировки строк от изменений?

Странные и противоречивые требования - весь код работает на уровне грязного чтения, но хочу блокировки на изменение/удаление....
dirty read есть зло для серьезных многопользовательских систем и его использование может быть оправдано только чрезмерными требованиями к скорости (типа риалтайм) и согласием на неконсистентность данных.
Никаких искуственных блокировок создавать не нужно - за вас все сделает сервер (иногда даже избыточно), нужно только правильно выбрать уровень изоляции, с которым должны работать ваши приложения. Очень рекомендую почитать на эту тему.

P.S. А вот эти "изобретения", типа "update ... set <column>=<column>" никому не показывайте, а то ведь грамотный внедренец или заказчик и убить может :)

...

Рейтинг:

0 / 0

10.03.2006, 20:00

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593868

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

softic onstat- set isolation ...
тогда надо менять уровень изоляции - а без этого никак?

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

Ваш случай с dirty read
в народе называется "против лома нет приема".

...

Рейтинг:

0 / 0

10.03.2006, 20:07

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593873

softic

Гость

Коллеги, беда в том, что код уже написан "доблестными" разработчиками in-house системы... в обшем, dirty read и блокировки через update - это данность, и изменить её очень тяжело.

именно поэтому я и хотел узнать - есть ли варианты блокировок для моей ситуации? я не могу менять уровень изоляции, к сожалению; действительно, когда я увидел отчёты, работающий по несколько часов в dirty read - это пугает... на моей предыдущей работе за такое убили бы на месте (биллинговые системы такого не любят:)

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

если нет точечных блокировок - ок, буду дальше думать, что ещё можно поправить

...

Рейтинг:

0 / 0

10.03.2006, 20:12

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593884

onstat-

Участник

Сообщения: 8 199

Рейтинг: 0 / 0

softicКоллеги, беда в том, что код уже написан "доблестными" разработчиками in-house системы... в обшем, dirty read и блокировки через update - это данность, и изменить её очень тяжело.

именно поэтому я и хотел узнать - есть ли варианты блокировок для моей ситуации? я не могу менять уровень изоляции, к сожалению; действительно, когда я увидел отчёты, работающий по несколько часов в dirty read - это пугает... на моей предыдущей работе за такое убили бы на месте (биллинговые системы такого не любят:)

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

если нет точечных блокировок - ок, буду дальше думать, что ещё можно поправить

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

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

Здесь нужно правильно дизайнить если вам такие отчеты
дейтсвительно нужны.

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

...

Рейтинг:

0 / 0

10.03.2006, 20:23

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33593979

softic

Гость

отчёты я привёл в качестве примера абсолютно недостоверного чтения.

реально, задача не связана с отчётностью - это как раз в транзакционной части надо бы изменить методику блокировок.
на мой взгляд, блокировки через update должны больше нагружать систему, чем стандартные методы.

да и вообще, насколько я знаю, если в Oracle сделать select ... for update записи будут заблокированы от изменений - но почему в Informix так не получается?

...

Рейтинг:

0 / 0

10.03.2006, 22:29

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595511

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

softic...
да и вообще, насколько я знаю, если в Oracle сделать select ... for update записи будут заблокированы от изменений - но почему в Informix так не получается?
Какие интересные у вас выводы, на чем они основаны?

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.
37.
38.

session 1:
begin work;
SET ISOLATION TO dirty READ  RETAIN UPDATE LOCKS ;
select f0 from test for update;

session 2:
SET ISOLATION TO dirty READ;
set lock mode to wait 60;
update test set f0=f0 where 1=1;
    244: Could not do a physical-order read to fetch next row.
   154: ISAM error: Lock Timeout Expired 

in this time

[informix@ws-144 ~]$ onstat -u
IBM Informix Dynamic Server Version 10.00.UC3     -- On-Line -- Up 10 days 23:52:16 -- 27700 Kbytes

Userthreads
address  flags   sessid   user     tty      wait     tout locks nreads   nwrites
....
444fb4c8  L --PR-- 71       informix 2        44096a94 60   2     0        0
....
444fc44c Y--P--- 73       informix 4        44a5fa38 0    3     5        0
....


[informix@ws-144 ~]$ onstat -k

IBM Informix Dynamic Server Version 10.00.UC3     -- On-Line -- Up 10 days 23:52:27 -- 27700 Kbytes

Locks
address  wtlist   owner    lklist   type     tblsnum  rowid    key#/bsiz
44096884 0        444fb4c8 0            S    100002   205         0
440968dc 0        444fc44c 0        HDR+S    100002   205         0
44096a3c 0        444fc44c 440968dc HDR+IX   200066   0           0
44096a94 444fb4c8 444fc44c 44096a3c HDR+U    200066   100         0
44096aec 0        444fb4c8 44096884     IX   200066   0           0

...

Рейтинг:

0 / 0

13.03.2006, 08:52

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595558

Тан

Участник

Откуда: Череповец

Сообщения: 351

Рейтинг: 0 / 0

Код: plaintext

select ... for update

, однако в SPL оно приводит к изменяемой блокировке.

а чем вас не устраивает изменяемая блокировка? Она допускает чтение, но не допускает эксклюзивные блокировки, т.е. изменение/удаление.
Или вы говорите не о блокировке типа U ?

...

Рейтинг:

0 / 0

13.03.2006, 09:25

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595792

softic

Гость

Журавлев Денис softic...
да и вообще, насколько я знаю, если в Oracle сделать select ... for update записи будут заблокированы от изменений - но почему в Informix так не получается?
Какие интересные у вас выводы, на чем они основаны?

Денис, я просто подумал, что было бы логично, если функциональность языка SQL в вопросе постановки блокировок совпадала.

Журавлев Денис

Код: plaintext

1.
2.
3.
4.

session 1:
begin work;
SET ISOLATION TO dirty READ  RETAIN UPDATE LOCKS ;
select f0 from test for update;

Спасибо большое за помощь, про RETAIN UPDATE LOCKS я не знал.
Наверное, невнимательно читал документацию :(

Кстати, я сейчас просмотрел cahnge log для SQL - получается, что выражение RETAIN UPDATE LOCKS появилось только в 8.4, а мой клиент только готовится переходить с 7.3 на 9.4; видимо, в 7.3 можно было так блокировать только через update

...

Рейтинг:

0 / 0

13.03.2006, 10:56

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595833

Тан

Участник

Откуда: Череповец

Сообщения: 351

Рейтинг: 0 / 0

softicКстати, я сейчас просмотрел cahnge log для SQL - получается, что выражение RETAIN UPDATE LOCKS появилось только в 8.4, а мой клиент только готовится переходить с 7.3 на 9.4; видимо, в 7.3 можно было так блокировать только через update
версия 8 - это совсем другой сервер, не Dynamic, а Extended parallel. В нем очень большие отличия по SQL
и я не верю, что в 7.3 этого нет.

...

Рейтинг:

0 / 0

13.03.2006, 11:08

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595881

softic

Гость

Тан softicКстати, я сейчас просмотрел cahnge log для SQL - получается, что выражение RETAIN UPDATE LOCKS появилось только в 8.4, а мой клиент только готовится переходить с 7.3 на 9.4; видимо, в 7.3 можно было так блокировать только через update
версия 8 - это совсем другой сервер, не Dynamic, а Extended parallel. В нем очень большие отличия по SQL
и я не верю, что в 7.3 этого нет.

К сожалению, я не специалист по Informix, возможно в 7.3 такое выражение и было - но проверить я уже не смогу, т.к. под рукой нет живого тестового инстанса 7.3;

В конце-концов, в 9.4 это выражение точно есть, так что вопрос можно считать закрытым.

Ещё раз большое спасибо всем отозвавшимся! :-)

...

Рейтинг:

0 / 0

13.03.2006, 11:22

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595905

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

softicДенис, я просто подумал, что было бы логично, если функциональность языка SQL в вопросе постановки блокировок совпадала.:) Может почитаете документацию все-таки для разнообразия? Про ANSI-compliant database например. Про автокомит. Про то когда оракле транзакции "начинаются" когда в информиксе.

softicКстати, я сейчас просмотрел cahnge log для SQL - получается, что выражение RETAIN UPDATE LOCKS появилось только в 8.4, а мой клиент только готовится переходить с 7.3 на 9.4; видимо, в 7.3 можно было так блокировать только через updateПро как в 7-ке не знаю и проверить не могу. Но еще раз рекомендую внимательно прочесть документацию.
In an ANSI-compliant database, update cursors are usually not needed because any select cursor behaves the same as an update cursor without the RETAIN UPDATE LOCKS clause.

В общем вы ССЗБ.

...

Рейтинг:

0 / 0

13.03.2006, 11:28

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33595965

softic

Гость

Журавлев Денис softicДенис, я просто подумал, что было бы логично, если функциональность языка SQL в вопросе постановки блокировок совпадала.:) Может почитаете документацию все-таки для разнообразия? Про ANSI-compliant database например. Про автокомит. Про то когда оракле транзакции "начинаются" когда в информиксе.

Денис, можно вопрос - разве синтаксис select .. for update не работает в Oracle? Именно синтаксис? Ок, базы разные, в Informix я явно открываю транзакцию, а в Oracle нет - но синтаксис и смысл операции (думаю, это логично) должен быть одинаков?

Журавлев Денис softicКстати, я сейчас просмотрел cahnge log для SQL - получается, что выражение RETAIN UPDATE LOCKS появилось только в 8.4, а мой клиент только готовится переходить с 7.3 на 9.4; видимо, в 7.3 можно было так блокировать только через updateПро как в 7-ке не знаю и проверить не могу. Но еще раз рекомендую внимательно прочесть документацию.
In an ANSI-compliant database, update cursors are usually not needed because any select cursor behaves the same as an update cursor without the RETAIN UPDATE LOCKS clause.

В общем вы ССЗБ.
Спасибо большое за комплимент! К тому же Вы сами ССЗБ - читайте Вашу цитату выше: Д.Ж.same as an update cursor without the RETAIN UPDATE LOCKS clause
А мне нужно именно с RETAIN UPDATE LOCKS. Думаю, разница видна сразу?
Ещё раз спасибо за помощь, и, надеюсь, что тема закрыта.

...

Рейтинг:

0 / 0

13.03.2006, 11:42

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33596046

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

:) Не давай еще посчитаем кто из кто.

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.
23.
24.
25.
26.
27.
28.
29.
30.
31.
32.
33.
34.
35.
36.

session 1:
select f0 from informix.test where f0='1' for update; // start new transaction :)


session 2:
SET ISOLATION TO dirty READ;
set lock mode to wait 60;
update informix.test set f0=f0 where f0='1';

    243: Could not position within a table (informix.test).
   154: ISAM error: Lock Timeout Expired 


[informix@ws-144 ~]$ onstat -u

IBM Informix Dynamic Server Version 10.00.UC3     -- On-Line -- Up 11 days 02:59:26 -- 27700 Kbytes

Userthreads
address  flags   sessid   user     tty      wait     tout locks nreads   nwrites
...
444fb4c8 Y--P--- 79       informix 2        44b65f18 0    3     103      535
....
 444fc44c   L --PR-- 80       informix 4        44096bf4 60   1     4        0


[informix@ws-144 ~]$ onstat -k

IBM Informix Dynamic Server Version 10.00.UC3     -- On-Line -- Up 11 days 02:59:27 -- 27700 Kbytes

Locks
address  wtlist   owner    lklist   type     tblsnum  rowid    key#/bsiz
44096884 0        444fb4c8 0        HDR+S    100002   207         0
440968dc 0        444fc44c 0            S    100002   207         0
44096bf4  444fc44c  444fb4c8 44096884 HDR+SIX  10012e   0           0
44096c4c 0        444fb4c8 44096bf4 HDR+U    10012e   100         0

-----------------------------------------------------------
Решительный шаг вперед -- результат хорошего пинка сзади

...

Рейтинг:

0 / 0

13.03.2006, 11:57

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33596088

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

Нет наврал транзакция не началась, но insert/update/delete ее тем не менее стартуют.

-----------------------------------------------------------
Решительный шаг вперед -- результат хорошего пинка сзади

...

Рейтинг:

0 / 0

13.03.2006, 12:07

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33596150

softic

Гость

Код: plaintext

1.
2.
3.
4.
5.

# 1 :
select iid from onerow where iid =  1  for update;

# 2 :
update onerow set iid = iid where iid =  1 ;

Код: plaintext

1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
19.
20.
21.
22.

ids9 >onstat -k

IBM Informix Dynamic Server Version  9 . 40 .FC7     -- On-Line -- Up 23 days 16:02:32 -- 2165760 Kbytes

Locks
address          wtlist           owner            lklist           type     tblsnum  rowid    key#/bsiz
1b9c00f8          0                 6d8f99d0         1c5a1048         HDR+S     100002     301           0 
1c5a0d00          0                 6d8f99d0         1c5a1570             S     100002     101           0 
1c5a1048          0                 6d8f99d0         1c5a0d00         HDR+S     100002     305           0 
1c5a1570          0                 6d8f99d0          0                     S     100002    10b          0 
1c5a1750          0                 74c082f0         1c5a20b0             S     100002     101           0 
1c5a20b0          0                 74c082f0          0                     S     100002     301           0 
  22  active,  400000  total,  65536  hash buckets,  0  lock table overflows
ids9 >onstat -u

IBM Informix Dynamic Server Version  9 . 40 .FC7     -- On-Line -- Up 23 days 16:02:44 -- 2165760 Kbytes

Userthreads
address          flags   sessid   user     tty      wait             tout locks nreads   nwrites
6d8f99d0         Y--P--- 2078     informix W-0014C2 6fd0e528         0    4     92603    0
74c082f0         Y--P--- 2081     informix W-0014C2 704d89a8         0    2     90       0
  18  active,  256  total,  199  maximum concurrent

Денис, может я что-то не понимаю, даже, скорее всего так оно и есть - но на моей системе без RETAIN UPDATE LOCKS ничего не получается. То есть прекрасно проходит dml (update/delete).

Честно говоря, времени у меня очень мало на такие опыты - но, возможно попозже я ещё раз попробую почитать документацию и условия блокировок. Пока что (да и документация это говорит) - надо ставить RETAIN UPDATE LOCKS для блокировки записи от DML-выражений.

...

Рейтинг:

0 / 0

13.03.2006, 12:19

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33596243

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

RETAIN UPDATE LOCKS -- это решение для обычной бд.

Если вы хотите чтобы информикс работал как ansi совместимый, стартовал транзакции без "begin work", накладывал блокировки без RETAIN UPDATE LOCKS clause. тогда и бд создавайте как ansi "create database myansi with log_mode_ansi" (не помню синтаксис).

softic
Честно говоря, времени у меня очень мало на такие опыты - но, возможно ...Как на счет пять минут потерять потом за день долететь? :) Или наоборот?

...

Рейтинг:

0 / 0

13.03.2006, 12:42

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33596297

softic

Гость

Журавлев ДенисRETAIN UPDATE LOCKS -- это решение для обычной бд.

Если вы хотите чтобы информикс работал как ansi совместимый, стартовал транзакции без "begin work", накладывал блокировки без RETAIN UPDATE LOCKS clause. тогда и бд создавайте как ansi "create database myansi with log_mode_ansi" (не помню синтаксис).

Денис, так ведь у меня-то база не ANSI совместимая... :(
А ещё у неё кодировка знаешь, какая?? Вообще <en_US.819>.
Всё-таки не я администратор БД и не мне отвечать за конвертацию базы в ANSI-compatible, а также за комплексное тестирование всего ПО.

Журавлев Денис
softic
Честно говоря, времени у меня очень мало на такие опыты - но, возможно ...Как на счет пять минут потерять потом за день долететь?
Ну, вот ведь уже теряю :) однако, результаты мультфильма, думаю, помнят все? :)

В общем, теперь уж точно стало ясно, почему у нас получились разные результаты тестов. Пора бы точку поставить и вернуться к работе...

...

Рейтинг:

0 / 0

13.03.2006, 12:55

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33596640

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

softic...
Денис, так ведь у меня-то база не ANSI совместимая... :(
А ещё у неё кодировка знаешь, какая?? Вообще <en_US.819>.
Всё-таки не я администратор БД и не мне отвечать за конвертацию базы в ANSI-compatible, а также за комплексное тестирование всего ПО.Я про ANSI начал говорить из-за ваших намеков "а у нас в оракле ...", а я тоже могу вспомнить как там все хреново, и как сильно оракл отличается от анси и от информикса. И еще с такой кодировкой грех не читать документацию.

...

Рейтинг:

0 / 0

13.03.2006, 14:02

| Ответить | Цитировать | Написать

select ... for update vs. update ... set <column>=<column>

#33599145

Журавлев Денис

Участник

Откуда: St.John,NB,CA

Сообщения: 5 515

Рейтинг: 0 / 0

Еще раз проверил, про ansi бд я наврал, если обе сессии в dr, то не получается блокировка. Единственный выход RETAIN UPDATE LOCKS.

-----------------------------------------------------------
Решительный шаг вперед -- результат хорошего пинка сзади

...

Рейтинг:

0 / 0

14.03.2006, 12:52

| Ответить | Цитировать | Написать

22 сообщений из 22, страница 1 из 1

Форумы / Informix [игнор отключен] [закрыт для гостей] / select ... for update vs. update ... set <column>=<column>

Читали тему (0):

Читали форум (0):

Пользователи онлайн (0):

start [/forum/topic.php?fid=44&fpage=52&tid=1608727]:	0ms
get settings:	6ms
get forum list:	15ms
check forum access:	4ms
check topic access:	4ms
track hit:	24ms
get topic data:	9ms
get forum data:	2ms
get page messages:	53ms
get tp. blocked users:	1ms
others:	195ms

total:	313ms

	Необходимые cookie
	Cookie для сбора статистики
	Cookie для маркетинга и рекламы