1. как выглядит, что не получил эффекта?
2. приведи SELECT

1. а ты знаешь, что если ты выполняешь подобное без NOWAIT и кто-то уже заблокировал хотя бы одну строку из нужных тебе, то перейдешь в ожидание до освобождения блокировки?

2. не ответил на первый вопрос - как определяешь, что не получил эффекта

3. в некоторых версиях Oracle после UPDATE нужно было указывать имя поля (любого), которое хочешь изменять. М.б. в PB эта фича осталась?

4. кавычки не обязательны

Попробуй посмотреть так
1. в PB выполняешь SELECT FOR UPDATE
2. в PLSQL Developer смотришь v$session и находишь SID сессии с PB
3. в v$lock смотришь, появились ли строки для сессии с PB. Если нет - значит действительно строки не блокируются (FOR UPDATE не выполняется)

Встречался с неполной совместимостью PB и Oracle (PB7 и Oracle8), когда запрос, выполнявшийся в SQL Navigator, вызывал ошибку в PB. Обход подобных ситуаций - создать процедуру на сервере, а в PB возвращать курсор

Филипп AIZДоброго времени суток всем! PB9, ORACLE 9. Требуется заблокировать выбранные строки таблицы в DW и DS. Вопрос, собственно, в следующем: можно ли в DW и DS использовать SELECT ... FOR UPDATE для блокировки выборки? Я впрямую написал это, но эффекта не получил. Есть ли какие-либо соображения по этому поводу? Спасибо.
Как обычно, придётся спросить, а зачем?

Иногда требуется по бизнес-условиям (например - редактирование одного документа)

Anatoly Moskovsky tru55 Филипп AIZSELECT ... FOR UPDATE а зачем?
Иногда требуется по бизнес-условиям (например - редактирование одного документа)
Т.е. предлагается держать транзакцию открытой в течении всего времени редактирования документа (а в итоге и перекура и обеда, да помножем на кол-во одновременно открытых документов :)?
Оракл конечно с этим справляется на ура, но только для небольшого числа юзеров - система получается немасштабируемой (экспоненциальное возрастание требований к ресурсам сервера при линейном возрастании кол-ва пользователей).

Для блокировок документов существуют множество других (нетребовательных к ресурсам сервера) способов.

1. это извечный спор между опимистическим и пессимистическим блокированием :)
В некоторых случаях хорошо одно, в некоторых другое. Я бы не стал однозначно отрицать ни то, ни другое

2. кол. одновременно открытых на редактирование документов, как правило, не больше кол. работающих пользователей (а в реальности значительно меньше)

3. экспоненциальное возрастание требований к ресурсам сервера
Позвольте спросить - к каким ресурсам? И при каком кол. пользователей реально возникнут трудности?

4. Для блокировок документов существуют множество других способов
Все известные мне способы не лишены недостатков

PS ну и вопрос не совсем для этого топика :)

18-я весна tru551. это извечный спор между опимистическим и пессимистическим блокированием :)
В некоторых случаях хорошо одно, в некоторых другое. Я бы не стал однозначно отрицать ни то, ни другое

2. кол. одновременно открытых на редактирование документов, как правило, не больше кол. работающих пользователей (а в реальности значительно меньше)

3. экспоненциальное возрастание требований к ресурсам сервера
Позвольте спросить - к каким ресурсам? И при каком кол. пользователей реально возникнут трудности?

4. Для блокировок документов существуют множество других способов
Все известные мне способы не лишены недостатков

PS ну и вопрос не совсем для этого топика :)

1 - Нет, я про другое. Почувствуйте разницу: "пессимистическая блокировка документов" - это "что сделать", а "блокирование строк таблицы на время транзакции" - это "как сделать". Ту же пессимистическую блокировку можно и по другому сделать.

2 - Нет такого правила (не больше одного). Зато есть законы Мерфи. Если программа разрешает открыть больше одного, значит пользователь откроет.
Надо так строить систему, чтобы любое кол-во открытых документов никак не сказывалось на производительности сервера.

3 - например RAM и UNDO

4 - Да. Я привел недостатки этого способа.

PS - Ну так пока автор отвечает Филиппу на вопрос "зачем?", нам есть чем заняться :)

1. сделать по другому - это как? Кроме того, SELECT FOR UPDATE - стандартный способ, которй Oracle предоставляет разработчику и которым пользуется сам. Зачем еще изобретать велосипед?

2. а где было сказано, что программа позволяет открыть больше одного документа? Лично я считаю, что открывать больше 1 на РЕДАКТИРОВАНИЕ (не на просмотр) не имеет смысла - это неестественно для человека

3. RAM - это что? В терминологии Oracle есть понятие SGA. Какие структуры для этого задействованы в данном случае? Если buffer cache, дык блоки все равно туда читаются, вне зависимости от того, просто я смотрю документ или накладываю блокировки на строки.
UNDO тратится при изменении данных, а не при SELECT FOR UPDATE

4. по поводу пункта 4 - не понял ответа...

Anatoly Moskovsky tru55
1. сделать по другому - это как? Кроме того, SELECT FOR UPDATE - стандартный способ, которй Oracle предоставляет разработчику и которым пользуется сам. Зачем еще изобретать велосипед?

2. а где было сказано, что программа позволяет открыть больше одного документа? Лично я считаю, что открывать больше 1 на РЕДАКТИРОВАНИЕ (не на просмотр) не имеет смысла - это неестественно для человека

3. RAM - это что? В терминологии Oracle есть понятие SGA. Какие структуры для этого задействованы в данном случае? Если buffer cache, дык блоки все равно туда читаются, вне зависимости от того, просто я смотрю документ или накладываю блокировки на строки.
UNDO тратится при изменении данных, а не при SELECT FOR UPDATE

4. по поводу пункта 4 - не понял ответа...

1 - а кто сказал что надо изобретать? Взять готовое решение. Их множество и они обсуждались много раз по всему инету и на sql.ru в частности.
2 - это Вы скажите нашим бухгалтерам :)
3 - каждая блокировка документа требует отдельного сеанса, а на них уходит память, а она конечна. Undo - если в ходе редактирования создаются временные данные на сервере.
4 - Еще раз. Все способы имеют недостатки. Но недостаток этого способа - немасштабируемость . При большой нагрузке он играет основную роль.

1. Готовое решение - это как раз SELECT FOR UPDATE.
Другие - как-то не очень знаю
Если, например, изменять какой-либо флаг в колонке таблице - это еще более требовательно к ресурсам (UNDO, REDO и т.д)
2. не знаю ваших бухгалтеров У меня таких прецендентов не было
3. каждая блокировка документа требует отдельного сеанса
Ет-т-то еще с какого перепуга?
Undo - если в ходе редактирования создаются временные данные на сервере
- ни о каких временных данных речь не шла - только о SELECT FOR UPDATE
- что вообще подразумевается под временными данными? Это понятие можно трактовать очень широко
4. вот насчет немасштабируемости у меня большие сомнения. Кроме того, я уже задавал вопрос - при каком кол. одновременно работающих пользователей это может сказаться? Несколько десятков, сотен, тысяч?