ReSQL.ru
     
powered by simpleCommunicator - 2.0.59     © 2025 Programmizd 02
Мобильная версия    Контакт    Правила    FAQ    Помощь
Целевая тема:
Создать новую тему:
Автор:
Закрыть
Цитировать
Доб. в избранное | Игнор. тему | Прикреп. тему | Пометить прочит. / непрочит. | Фильтр
Форумы / Oracle Forms [игнор отключен] [закрыт для гостей] / FRM-40657
14 сообщений из 14, страница 1 из 1
FRM-40657
    #37246978
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
При попытке обновления записи в форме вылазит такая ошибка FRM-40657. От куда Формсы узнают что этой записи нет в БД?
Предыстория возникновения ошибки:
1) Есть блок БД, в нём выбраны записи
2) По кнопке, все значения текущей записи сохраняются во временных переменных и сама запись прочищается (через clear_record)
3) По другой кнопке, запись обратно восстанавливается, через
Код: plaintext
1.
2.
3.
4.
create_record;
-- Дальше идёт присваивание всем полям ранее сохранённых значений
-- И меняем статус строки
set_record_property(:SYSTEM.CURSOR_RECORD ,v_block_name,STATUS,QUERY_STATUS);
Вот откуда формсы узнают, что эту запись я сам добавил, а не он считал из БД ? Можно его как-то обмануть? Перезапрашивать данные - не вариант - слишком тяжёлый запрос.
...
Рейтинг: 0 / 0
05.05.2011, 12:05
| Ответить | Цитировать | Написать  
FRM-40657
    #37247032
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
Ura!,

Мой был косяк, триггер стоял, который первичный ключ заново генерил.
Это поправил, но проблема осталась. Теперь выдаёт ошибку
FRM-40654, Запись обновлена другим пользователем.
Откуда он узнал, что его кто-то обновил, если её по сути никто не обновлял.
...
Рейтинг: 0 / 0
05.05.2011, 12:26
| Ответить | Цитировать | Написать  
FRM-40657
    #37247059
Maratus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maratus
Участник
Ura!,
А попробуйте посмотреть - какой реальный статус у строки после всех ваших манипуляций.
...
Рейтинг: 0 / 0
05.05.2011, 12:34
| Ответить | Цитировать | Написать  
FRM-40657
    #37247096
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
Статус QUERY пишет
...
Рейтинг: 0 / 0
05.05.2011, 12:46
| Ответить | Цитировать | Написать  
FRM-40657
    #37247272
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
Так и не понял, как он определяет что запись изменилась и как его обмануть. Если кто знает, отпишитесь, чтобы не городить огород (см. далее)
Придумал такой workarround, в нём есть косяк, его конечно тоже можно полечить, но для меня он не критичен.
Косяк:
Если запустить форму в двух разных сессиях, сделать выборку данных и в одной сессии изменить значение в строке и сохранить. То вторая сессия об этом не будет знать ни сном ни духом и эту же самую строку тоже сможет обновить, затерев изменения первой.
Теперь воркэраунд:
1) Создал на блок свой триггер ON-LOCK, в нём сам лочу строку (с помощью курсора for update). LOCK_RECORD не использую!!!
2) В блоке выставил следующие свойства:
Код: plaintext
1.
2.
Enforce Primary Key = Yes
Key Mode = Updateable
3) Ну и в блоке указал первичный ключ.

Во время придумывания этого решения, напоролся на несколько граблей, так до конца и не поняв поведение формсов. Может кто объяснит?
1) Если в ON-LOCK LOCK_RECORD не использовать, а свойства у блока будут такие:
Код: plaintext
1.
2.
Enforce Primary Key = NO
Key Mode = Unique
то при изменении строки идёт ошибка "ORA... NO DATA FOUND и FRM... Oracle не может обновить запись"
Я так понял, что при использовании LOCK_RECORD, формсы запоминают где-то у себя ROWID и потом при обновлении его используют, если же мы не вызывали LOCK_RECORD, то он не знает какой ROWID у записи и валится в такую непонятную ошибку.
2) Если в дополнение своей блокировки вставить всё таки LOCK_RECORD, то приходим к тому от чего ушли: FRM-40654, Запись обновлена другим пользователем.
...
Рейтинг: 0 / 0
05.05.2011, 13:47
| Ответить | Цитировать | Написать  
FRM-40657
    #37248930
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-=APS=-
Участник
Чтобы не городить огород, давайте все-таки уточним задачу.
Я так понял, у вас есть некий долгоиграющий запрос, результаты которого вы показываете пользователю. После чего, пользователь выбирает некую строку и что-то должен с ней сделать. Вот это "что-то" мне и непонятно - зачем делать clear_record, а затем имитировать другие данные в этой строке, как будто она был выбрана из базы? Как-то странно. Что пользователю нужно получить в итоге (т.е., не в терминах clear_record/create_record, а человеческими словами)? :)
...
Рейтинг: 0 / 0
06.05.2011, 09:51
| Ответить | Цитировать | Написать  
FRM-40657
    #37249089
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
Есть два блока, один БД с долгоиграющим запросом, второй блок не БД.
Пользователь по кнопке перекидывает как бы строчку из одного блока в другой (формирует список). При перекидывании записи во второй блок из первого она пропадает (clear_record). Но пользователь может и обратно перекинуть запись в первый блок.
Тогда из второго блока она пропадает, а вот в первом должна появиться.
...
Рейтинг: 0 / 0
06.05.2011, 10:51
| Ответить | Цитировать | Написать  
FRM-40657
    #37249154
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-=APS=-
Участник
Может, вам проще будет построить не-database блоки, а сформировать их на when-new-block-instance?
...
Рейтинг: 0 / 0
06.05.2011, 11:12
| Ответить | Цитировать | Написать  
FRM-40657
    #37249211
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
-=APS=-,

Боюсь, загнутся формсы. В блоке БД > 100 тыс. записей.
...
Рейтинг: 0 / 0
06.05.2011, 11:26
| Ответить | Цитировать | Написать  
FRM-40657
    #37249716
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-=APS=-
Участник
И пользователь просматривает все 100 тыс строк визуально? Гм... Три раза гм...
...
Рейтинг: 0 / 0
06.05.2011, 14:37
| Ответить | Цитировать | Написать  
FRM-40657
    #37249745
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
Конечно не просматривает. Но если взять идею блока не БД и заполнять его при входе. Я может неправильно понял, или чего-то не знаю, разве не придётся тогда загнать в него все записи?
...
Рейтинг: 0 / 0
06.05.2011, 14:51
| Ответить | Цитировать | Написать  
FRM-40657
    #37249833
Maratus
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Maratus
Участник
Ura!,
У блока есть свойство - Query All Records(Запросить Все Записи)
Код: plaintext
1.
2.
3.
4.
Specifies whether all the records matching the query criteria should be fetched 
into the data block when a query is executed.
 Yes  - Fetches all records from query; equivalent to executing the EXECUTE_QUERY 
(ALL_RECORDS) built-in.
 No  - Fetches the number of records specified by the Query Array Size block property.
Если Query All Records = No , то в блог сразу все строки не будут загружены,
а загрузится столько сколько вы указали в Number of Records Displayed.
...
Рейтинг: 0 / 0
06.05.2011, 15:23
| Ответить | Цитировать | Написать  
FRM-40657
    #37249904
-=APS=-
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
-=APS=-
Участник
авторКонечно не просматривает. Но если взять идею блока не БД и заполнять его при входе. Я может неправильно понял, или чего-то не знаю, разве не придётся тогда загнать в него все записи?Да, в этом сысле, вы правы.
Но все-таки, лично для меня очень сомнительна идея выборки, которая потенциально может выдать пользователю 100 тыс строк для просмотра/анализа.
В идеале, описанная вами форма должна была бы предоставлять возможность быстрого поиска необходимых данных по внятным критериям, которые бы мог указывать пользователь, а затем он бы добавлял кнопкой некоторые из строк в свою "буферную зону". Но вы заранее поставили достаточно "злобные" условия - выборка долгоиграющая :) Может, потому и долгоиграющая, что возвращает 100 тыс строк? :)

Кстати, а обязательно ли убирать строки из первого блока? Может, их просто покрасить в альтенативный цвет в instance property?
...
Рейтинг: 0 / 0
06.05.2011, 15:52
| Ответить | Цитировать | Написать  
FRM-40657
    #37249912
Ura!
Скрыть профиль Поместить в игнор-лист Сообщения автора в теме
Ura!
Участник
-=APS=-Кстати, а обязательно ли убирать строки из первого блока? Может, их просто покрасить в альтенативный цвет в instance property?
А это идея, спасибо.
...
Рейтинг: 0 / 0
06.05.2011, 15:55
| Ответить | Цитировать | Написать  
14 сообщений из 14, страница 1 из 1
Форумы / Oracle Forms [игнор отключен] [закрыт для гостей] / FRM-40657
Найденые пользователи ...
Разблокировать пользователей ...
Читали тему (0):
Читали форум (0):
Пользователи онлайн (0):
Польз. соглашение
NoSQL.ru       Новости, Чат       Фотоальбом: Участники, Встречи
Закрыть
start [/forum/topic.php?fid=51&fpage=22&tid=1878716]:
 0ms
get settings:
 8ms
get forum list:
 12ms
check forum access:
 3ms
check topic access:
 3ms
track hit:
 49ms
get topic data:
 11ms
get forum data:
 2ms
get page messages:
 74ms
get tp. blocked users:
 2ms
others: 11ms
total:  175ms
созд. / загр.: 175ms
x
x
Закрыть


Просмотр
0 / 0
Close
Debug Console [Select Text]