SAPфорум.RU https://www.sapboard.ru/forum/ |
|
CALL FUNCTION '' IN UPDATE TASK https://www.sapboard.ru/forum/viewtopic.php?f=13&t=13945 |
Страница 1 из 2 |
Автор: | G [ Пн, апр 10 2006, 16:07 ] |
Заголовок сообщения: | CALL FUNCTION '' IN UPDATE TASK |
В BSP-скрипте вызываю функцию в UPDATE TASK. Функция вставляет данные в таблицы и работает с функциями BPS. В диалоговом режиме все работает корректно. В UPDATE TASK работает около 2-х минут, потом завершает работу, результатов которой не видно Что может быть? (если нужны уточнения - сообщу) Может такая функция ничего не должна возвращать (в описании EXPORTING нет, есть только TABLES)? Или наоборот что-то должна возвращать? В свойствах выставлено: Модуль обновления -> Немедленный запуск Спасибо! |
Автор: | Loyso [ Пн, апр 10 2006, 16:11 ] |
Заголовок сообщения: | |
она изменяет таблицы БД? |
Автор: | G [ Пн, апр 10 2006, 16:12 ] |
Заголовок сообщения: | |
Да... |
Автор: | Loyso [ Пн, апр 10 2006, 16:12 ] |
Заголовок сообщения: | |
COMMIT WORK. не забыли??? |
Автор: | G [ Пн, апр 10 2006, 16:51 ] |
Заголовок сообщения: | |
Хороший вопрос! В вызывающем есть и в вызываемом есть Я тут еще погонял функцию, выпадает в дамп на ROLLBACK WORK. |
Автор: | Loyso [ Пн, апр 10 2006, 16:54 ] |
Заголовок сообщения: | |
А почему??? |
Автор: | G [ Пн, апр 10 2006, 16:57 ] |
Заголовок сообщения: | |
ROLLBACK is not allowed during an update (CALL FUNCTION ... IN UPDATE TASK) хм... а как бы и рыбку и ... т.е. асинхронно вызвать функцию и чтоб коммит или ролбэк в ней отработал корректно. |
Автор: | Сергей Королев [ Пн, апр 10 2006, 17:34 ] |
Заголовок сообщения: | |
Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции. |
Автор: | Loyso [ Вт, апр 11 2006, 08:45 ] |
Заголовок сообщения: | |
Сергей Королев написал: Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции.
О как! Надо будет запомнить. А причину такого запрета в двух словах не опишите????? |
Автор: | Кодер [ Вт, апр 11 2006, 09:24 ] |
Заголовок сообщения: | |
2 G: Нужно просто правильно продумать процедуру сохранения. Тогда возможно отпадет вариант с не совсем верными желаниями 2 Loyso: А это просто принцип сохранения такой. Модули, которые вызываются в UPDATE TASK начинают свою работу, в тот момент, когда в вызывающей программе отрабатывает COMMIT WORK. Т.е. вызываете последовательно несколько таких модулей, потом один раз говорите коммит и все обновления массой сливаются в базу. Подробнее - курс BC 414 + help на слова LUW и "обработка транзакций" |
Автор: | EGF [ Ср, апр 12 2006, 09:38 ] |
Заголовок сообщения: | |
Loyso написал(а): Сергей Королев написал: Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции. О как! Надо будет запомнить. А причину такого запрета в двух словах не опишите????? Дело в том, что COMMIT WORK есть в том числе и явный вызов database commit. А если внутри одного из модулей обновления в процессе самого обновления отработает database commit, то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления. Поэтому внутри модулей обновления запрещены все операторы, которые могут спровоцировать - явно или неявно - database commit или database rollback. |
Автор: | Loyso [ Ср, апр 12 2006, 09:51 ] |
Заголовок сообщения: | |
Спасибо за инфо |
Автор: | G [ Ср, апр 12 2006, 10:34 ] |
Заголовок сообщения: | |
Вполне понятно почему нельзя делать коммит в UPDATE TASK (мне нужен был асинхронный режим выполнения ФМ потому я перешел на использование BACKGROUND TASK там коммит -- не преступление). Можно поподробнее вот об этом: Цитата: то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления. ?
Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно. Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?). |
Автор: | EGF [ Ср, апр 12 2006, 12:32 ] |
Заголовок сообщения: | |
G написал: Вполне понятно почему нельзя делать коммит в UPDATE TASK
(мне нужен был асинхронный режим выполнения ФМ потому я перешел на использование BACKGROUND TASK там коммит -- не преступление). Можно поподробнее вот об этом: Цитата: то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления. ?Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно. Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?). Дело в том, что когда в программе выполняется последовательность модулей обновления Вы вольны делать database commit когда угодно - на обновление БД это не повлияет. Полная последовательность этих модулей будет выполнена (или не выполнена) в процессе обновления, который буде запущен после COMMIT WORK. Когда же выполняется непосредственно обновление внутри процесса обновления операторы, инициирующие database commit/rollback внутри модулей обновления делят весь процесс на части. Если интересно, посмотрите по-подробнее о понятиях Database LUW и SAP LUW. |
Автор: | Кодер [ Ср, апр 12 2006, 13:48 ] |
Заголовок сообщения: | |
Цитата: Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно.
Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?). 1) Можно вызвать обновления БД непосредственно в программе, тогда в случае сбоя, все обрабатывать надо самому + т.к. СУБД по традиции это узкое место : занимаются ресурсы, что есть нехорошо. 2) Обновления в UPDATE TASK или гарантировано все доедут или гарантированно все не доедут в рамках 1-ого LUW. В случае, если они не доехали, есть возможность через sm13 посмотреть и как-то исправить ситуацию. Так же, т.к. это работает через предопределенные разработчикми Р3-механизмы, достигается экономия ресурсов. Самое главное: это не асинхронный вызов, т.е. по идее программа дождается подтверждения сохранения.(Как пример: можно воткнуть точку остановки в проводке, когда она будет достигнута - остановить обновления в системе, и продолжить проводку. Все повиснет ) 3) BACKGROUND TASK - асинхронный вызов + транзакционный вызов в RFC |
Страница 1 из 2 | Часовой пояс: UTC + 3 часа |
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group http://www.phpbb.com/ |