wolf_sv написал(а):
Ответ на 1 вопрос (Правильно ли я понял, что при ручном вводе таких проблем не возникает?):
С такой проблемой я столкнулся при пакетном вводе. Настораживает то, что такая ситуация возникает не по всем основным средствам. По каким то основным средствам, у которых более 2 субномеров (например, 19 субномеров), на их основании благополучно создаются новые карточки через транзакцию AS11. Хочу обратить ваше внимание на такой ещё факт. Когда у меня случается такая ситуация при пакетном вводе, то я пытаюсь в ручном режиме на основании того же основном средства, на котором случилась данная ситуация, создать следующий по порядку новый субномер (как я уже описывал в верху последний был создан субномер 2 на ОС №1110006454, а я пытаюсь через тр AS11 создать новую карточку с новым субномером 3), то при запуске транзакции AS11 и после ввода ОС, БЕ, Число субномеров одного вида(1) на экране появляется карточка на новый субномер ОС, в которой в качестве нового субномера (3) ОС опять фигурирует уже существующий предыдущий субномер(2). Получается и в ручном режиме я столкнулся с аналогичной ситуацией по данному основному средству №1110006454.
Уточнение по вашему высказыванию (Есть подозрение что система не успевает создать ОС с субномером X, и заходит уже на создание следующего субномера для этой ОС, тем более что Вы пишите якобы это бывает периодически...):
Под словом «периодически» я предполагаю, что данная ситуация возникает на некоторых основных средствах. Я думаю, что система создаёт новый субномер ОС, но система ПОЧЕМУ ТО НЕ ПРОПИСЫВАЕТ вновь созданный субномер в том месте, откуда система считывает его для определения нового следующего субномера (например, если взять выше описанную ситуацию, то был создан субномер 2, но по каким то причинам в том месте остался субномер 1, а должен был быть уже субномер 2 для определения следующего нового субномера 3 в момент его создания). Скорее всего система не не успевает, потому что по прохождению времени ситуация не исправляется и я также в ручном режиме через тр AS11 не могу создать карточку на ОС № 1110006454 с новым субномером (3) следующим по порядку за уже существующим субномером (2).
В ручном режиме этого же прогона пакетника, без перезапуска тр AS11? Опять таки, сколько времени не жди, а старый номер весит в глобальной переменной... На счет числа субномеров, я не владею особенностями этой транзакции, но то что там единица, это нормально? Принцип работы получения нового субномера заключается в том что система выбирает последний ОС по субномеру и увеличивает его номер. ФМ NUMBER_GET_NEXT не используется... В следствие чего вопрос? Вы смотрели и пробовали ли ссылку которую я указал в посте выше?
Цитата:
Ответ на 3 вопрос (Обновление прервано это дамп, что там написано?):
Когда я сохраняю предлагаемую мне карточку в тр AS11, система в строке статуса пишет что основное средство №1110006454 с субномером 2 создано. НО в этот же момент у меня во входящей почте (Рабочее место) появляется письмо, в теле которого написано:
[i]Обновление прервано
Из анализа дампа по приведённому фрагменту программного кода видно, что ошибка возникает в момент вставки записи в таблицу «ANLA». Эта ситуация понятна, в таблице ANLA ключ : БЕ, № ОС, Субномер, а т.к. через тр AS11 у нас для новой карточки в качестве субномера опять указан существующий (2) вместо 3, то при сохранении данных система отказывает сохранить данные с уже существующим ключом: БЕ 2000, № ОС 1110006454, Субномер 2. НО это следствие, а в чём причина? Не понятно.
Из дампа взял предлагаемые фрагменты для поиска нот:
"SAPSQL_ARRAY_INSERT_DUPREC"
"SAPLA02S " or "LA02SF00 "
"INSERT_ENTRIES"
По фрагменту "SAPSQL_ARRAY_INSERT_DUPREC" нашёл две: 99029, 118731 более менее близкие. Но из текста этих нот я пока не могу сказать, что эта именно в этом проблема. Надо проверять.
Это все нормально, на самом деле ничего не сохранилось конечно, потому что в очереди ФМов обновления произошел дамп и весь LUW откатился. Ноты конечно проверьте.
Вход
Регистрация
FAQ пользователя
Поиск
