2 транзакции подряд в пакетном режиме

Uukrul

Любаша написал(а):

Попытаюсь объяснить.
1. Создается некая запись (уж буду партизаном

извиняйте) в 1 транзакции. Тут же в моей проге запускается 2 транзакция на редактирование этой вновь созданной записи.
2. Вот тут и возникает иногда ошибка типа "Запись такая-то не создана", хотя она есть!
3. При создании новой записи никаких блокировок по объектам нет - я проверяла. То есть в SM12 пусто. Видимо, INSERT не делает блокировку, только UPDATE.
4.Abap дал мне хороший совет - в этом ФМ проверяется не блокировка, а работа самой транзакции. Когда работа транзакции 1 завершена - можно запускать вторую.

Если 1 транзакция как я понял это стандарт а вы просто в каком-то экзите вызываете что-то другое свое, то вообще-то конечно можно было это обойти по другому... а все таки что за траназакция такая секретная?

ABC

Может хотя бы в личку заинтересованным лицам напишите что за транзакции такие загадочные.
Ну очень интересно...

Uukrul

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

А имена транзакции... Кстати никто не знает ФСБ часом R/3 не внедряет? А то у меня сложилось впечатление что это транзакции получить список секретных агентов и вторая расстрелять двойных агентов

Любаша

Должна же быть в женщине какая-то загадка! :lol:

ABC

Любаша написал(а):

Должна же быть в женщине какая-то загадка! :lol:

Если женщина, загадав загадку, не дает мужчине шанса эту загадку разгадать, то, весьма вероятно, что в следующий раз ей придется искать нового мужчину для загадывания... :wink:

sibrin

Цитата:

3. При создании новой записи никаких блокировок по объектам нет - я проверяла. То есть в SM12 пусто. Видимо, INSERT не делает блокировку, только UPDATE.

Операторы SQL влекут блокировки на уровне БД. Причём, как правило, запрета на чтение нет, если не ошибаюсь, т.е. в момент модификации можно прочитать предыдущее консистентное состояние.

SM12 тут ни при чём. Если скрываемые Вами транзакции самодельные, то ничего удивительного в том, что блокировки не устанавливаются.

Uukrul

Мда, чего-то я устал в загадки-отгадки играть...

Любаша

Я тоже устала. Никто мне так толком и не объяснил, зачем брать конкретную транзакцию, какое это иметь значение для определения, доработала транзакция до конца, или нет. Ведь этот механизм общий для системы. Хорошо, Возьмите ME31k (создание) и ME32K (редактирование). При создании нет объектов блокировки. При редактировании - есть.
Создайте ввод новой записи , а затем в пакетнике - редактирование вновь созданной (предположим, для добавления каких-то параметров, которые нельзя сделать с помощью юзер-экситов). Всё это поместите подряд в одном отчёте.

Ситуация может возникнуть в любом месте с любыми транзакциями.

sibrin

Цитата:

При создании нет объектов блокировки. При редактировании - есть.

Конечно есть. Только при создании блокировка живёт очень недолго.

Удав

Ну вот, так то лучше.
Объект блокирования, как было видно из режиме редактирования, EMEKKOE.
Аргумент блокирования (номер нового контракта) можно узнать из таблицы сообщений (заполняется при вызове call transaction) по области сообщения 06 и номеру сообщения 017.
В поле MSGV1 будет лежать номер созданного документа.

Code:

...
SET UPDATE TASK LOCAL.
....
CALL TRANSACTION 'ME31K' ... MESSAGES INTO it_mess.

read table it_mess wtih key msgid = '06' msgno = '017'.
CLEAR found.
if sy-subrc = 0.
  r_ebeln = it_mess-msgv1.
  do 500 times.
    call function 'ENQUEUE_EMEKKOE'
      exporting
        ebeln = r_ebeln
      exception
        others = 1.
    if sy-subrc <> 0.
      call function 'ENQUE_SLEEP'
        exporting
          seconds = 1.
    else.
      found = 'X'.
      call function 'DEQUEUE_EMEKKOE'
        exporting
          ebeln = r_ebeln
        exception
          others = 1.

      exit.
    endif.
  enddo.
endif.
if found = 'X'.
  CALL TRANSACTION 'ME32K' ....
else.
  MESSAGE e208(00) with 'Контракт заблокирован'.
endif.

Любаша

Я уже объясняла выше, что в команде CALL TRANSACTION нельзя использовать

Code:

AND SKIP FIRST SCREEN

вместе с

Code:

MESSAGES INTO it_mess

holocron

Любаша написал(а):

Я уже объясняла выше, что в команде CALL TRANSACTION нельзя использовать

Code:

AND SKIP FIRST SCREEN

вместе с

Code:

MESSAGES INTO it_mess

а что если вместо and skip first screen заполнить корректно bdcdata?

Любаша

Предлагаю закончить тему.

Как резюме:

Есть 2 варианта.
1. То, что предложил УДАВ
2. То, что предложил ABAP:

Code:

*&---------------------------------------------------------------------*
*&      Form  proverka
*&---------------------------------------------------------------------*
*       text
*----------------------------------------------------------------------*
*     ïðîâåðÿåì, ñäåëàíà òðàíçàêöèÿ, èëè åù¸ âèñèò
*----------------------------------------------------------------------*
FORM proverka  USING    value(p_tran)
      CHANGING   e_flg_ready.

  DATA vbkey LIKE vbhdr-vbkey VALUE IS INITIAL.
  DATA:
        vb_ok                           LIKE sy-index VALUE 0,
        vb_notexecuted                  LIKE sy-index VALUE 255,
        vb_hdr_insert                   LIKE sy-index VALUE 2.

  SELECT vbkey FROM vbhdr UP TO 1 ROWS
               INTO vbkey
               WHERE       vbmandt =       sy-mandt
                 AND       vbusr   =       sy-uname
                 AND       vbtcode =       p_tran
                 AND     ( vbrc    BETWEEN vb_ok
                                       AND vb_notexecuted )
                 AND NOT ( vbrc    BETWEEN vb_hdr_insert
                                   AND 200            )."#EC CI_NOFIELD
  ENDSELECT.
  IF sy-subrc = 0.
    e_flg_ready = 'X'.
  ELSE.
    e_flg_ready = ' '.
  ENDIF.
ENDFORM.                    " proverka

*Вызов: 
DATA: p_flg_ready TYPE esp1_boolean VALUE ' '.

CALL TRANZACTION call AND SKIP FIRST SCREEN.
      p_flg_ready = 'X'.
      WHILE p_flg_ready = 'X'.
        PERFORM proverka USING call CHANGING   p_flg_ready.
      ENDWHILE.

sibrin

Uukrul написал(а):

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

Т.е. сначала нужно из таблицы VBHDR получать VBENQKEY, а потом уже ждать блокировку? Или блокировка снимается в процессе VB, а потом UP2 может тормозить сколько угодно?

ABC

Любаша написал(а):

Я уже объясняла выше, что в команде CALL TRANSACTION нельзя использовать

Code:

AND SKIP FIRST SCREEN

вместе с

Code:

MESSAGES INTO it_mess

Номер проведенного документа скорее всего можно (для данной транзакции не проверял, но для FI-документа можно) получить из соответствующего SET/GET параметра. Перед вызовом транзакции его нужно почистить, а после завершения получить.

Правила форума

2 транзакции подряд в пакетном режиме

Кто сейчас на конференции