SAPфорум.RU
http://sapboard.ru/forum/

CALL FUNCTION '' IN UPDATE TASK
http://sapboard.ru/forum/viewtopic.php?f=13&t=13945
Страница 1 из 2

Автор:  G [ Пн, апр 10 2006, 17:07 ]
Заголовок сообщения:  CALL FUNCTION '' IN UPDATE TASK

В BSP-скрипте вызываю функцию в UPDATE TASK.
Функция вставляет данные в таблицы и работает с функциями BPS.

В диалоговом режиме все работает корректно.
В UPDATE TASK работает около 2-х минут, потом завершает работу, результатов которой не видно :(


Что может быть?
(если нужны уточнения - сообщу)
Может такая функция ничего не должна возвращать (в описании EXPORTING нет, есть только TABLES)?
Или наоборот что-то должна возвращать?
В свойствах выставлено:
Модуль обновления -> Немедленный запуск

Спасибо!

Автор:  Loyso [ Пн, апр 10 2006, 17:11 ]
Заголовок сообщения: 

она изменяет таблицы БД?

Автор:  G [ Пн, апр 10 2006, 17:12 ]
Заголовок сообщения: 

Да...

Автор:  Loyso [ Пн, апр 10 2006, 17:12 ]
Заголовок сообщения: 

COMMIT WORK.
не забыли???

Автор:  G [ Пн, апр 10 2006, 17:51 ]
Заголовок сообщения: 

Хороший вопрос!
В вызывающем есть
и в вызываемом есть
Я тут еще погонял функцию, выпадает в дамп на ROLLBACK WORK.

Автор:  Loyso [ Пн, апр 10 2006, 17:54 ]
Заголовок сообщения: 

А почему???

Автор:  G [ Пн, апр 10 2006, 17:57 ]
Заголовок сообщения: 

ROLLBACK is not allowed during an update (CALL FUNCTION ... IN UPDATE TASK)

хм... а как бы и рыбку и ...
т.е. асинхронно вызвать функцию и чтоб коммит или ролбэк в ней отработал корректно.

Автор:  Сергей Королев [ Пн, апр 10 2006, 18:34 ]
Заголовок сообщения: 

Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции.

Автор:  Loyso [ Вт, апр 11 2006, 09:45 ]
Заголовок сообщения: 

Сергей Королев написал:
Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции.


О как! Надо будет запомнить. А причину такого запрета в двух словах не опишите?????

Автор:  Кодер [ Вт, апр 11 2006, 10:24 ]
Заголовок сообщения: 

2 G: Нужно просто правильно продумать процедуру сохранения. Тогда возможно отпадет вариант с не совсем верными желаниями

2 Loyso: А это просто принцип сохранения такой. Модули, которые вызываются в UPDATE TASK начинают свою работу, в тот момент, когда в вызывающей программе отрабатывает COMMIT WORK. Т.е. вызываете последовательно несколько таких модулей, потом один раз говорите коммит и все обновления массой сливаются в базу. Подробнее - курс BC 414 + help на слова LUW и "обработка транзакций"

Автор:  EGF [ Ср, апр 12 2006, 10:38 ]
Заголовок сообщения: 

Loyso написал(а):
Сергей Королев написал:
Из кода функции обновления уберите COMMIT WORK - этого нельзя. COMMIT должен быть только в вызывающей функции.


О как! Надо будет запомнить. А причину такого запрета в двух словах не опишите?????


Дело в том, что COMMIT WORK есть в том числе и явный вызов database commit. А если внутри одного из модулей обновления в процессе самого обновления отработает database commit, то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления. Поэтому внутри модулей обновления запрещены все операторы, которые могут спровоцировать - явно или неявно - database commit или database rollback.

Автор:  Loyso [ Ср, апр 12 2006, 10:51 ]
Заголовок сообщения: 

Спасибо за инфо

Автор:  G [ Ср, апр 12 2006, 11:34 ]
Заголовок сообщения: 

Вполне понятно почему нельзя делать коммит в UPDATE TASK
(мне нужен был асинхронный режим выполнения ФМ потому я перешел на использование BACKGROUND TASK там коммит -- не преступление).

Можно поподробнее вот об этом:
Цитата:
то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления.
?
Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно.
Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?).

Автор:  EGF [ Ср, апр 12 2006, 13:32 ]
Заголовок сообщения: 

G написал:
Вполне понятно почему нельзя делать коммит в UPDATE TASK
(мне нужен был асинхронный режим выполнения ФМ потому я перешел на использование BACKGROUND TASK там коммит -- не преступление).

Можно поподробнее вот об этом:
Цитата:
то тогда может произойти ситуация, когда часть обновлений пройдёт, а часть - нет. А именно для того, чтобы избежать этой ситуации и был придуман механизм модулей обновления.
?
Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно.
Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?).


Дело в том, что когда в программе выполняется последовательность модулей обновления Вы вольны делать database commit когда угодно - на обновление БД это не повлияет. Полная последовательность этих модулей будет выполнена (или не выполнена) в процессе обновления, который буде запущен после COMMIT WORK. Когда же выполняется непосредственно обновление внутри процесса обновления операторы, инициирующие database commit/rollback внутри модулей обновления делят весь процесс на части.

Если интересно, посмотрите по-подробнее о понятиях Database LUW и SAP LUW.

Автор:  Кодер [ Ср, апр 12 2006, 14:48 ]
Заголовок сообщения: 

Цитата:
Для того чтобы прошли все обновления или ни одного был придуман механизм транзакций. А вот для чего механизм UPDATE TASK мне не очень понятно.
Предполагаю, чтобы асинхронно выполнить длительные вычисления в рамках текущей транзакции (тогда чем отличается от BACKGROUND TASK?).


1) Можно вызвать обновления БД непосредственно в программе, тогда в случае сбоя, все обрабатывать надо самому + т.к. СУБД по традиции это узкое место : занимаются ресурсы, что есть нехорошо.
2) Обновления в UPDATE TASK или гарантировано все доедут или гарантированно все не доедут в рамках 1-ого LUW. В случае, если они не доехали, есть возможность через sm13 посмотреть и как-то исправить ситуацию. Так же, т.к. это работает через предопределенные разработчикми Р3-механизмы, достигается экономия ресурсов. Самое главное: это не асинхронный вызов, т.е. по идее программа дождается подтверждения сохранения.(Как пример: можно воткнуть точку остановки в проводке, когда она будет достигнута - остановить обновления в системе, и продолжить проводку. Все повиснет :-) )
3) BACKGROUND TASK - асинхронный вызов + транзакционный вызов в RFC

Страница 1 из 2 Часовой пояс: UTC + 4 часа
Powered by phpBB © 2000, 2002, 2005, 2007 phpBB Group
http://www.phpbb.com/