Дали править программу одного программиста, которого прогнали за плохую работу. Думают, я буду лучше

И вот в числе других перлов вижу я такой абзац:

delete zpp_table from table gt_tab.
commit work and wait.


insert zpp_table from table gt_table.
commit work and wait.

gt_tab и gt_table - interne Tabellen
zpp_table - DB Tabelle

В gt_tab и gt_table данные почти одни и те же.
На строчке insert... программа дает думп, и данные при этом теряются, т.е. стираются, а обратно в таблицу не записываются. Что вызывает справедливый гнев клиентов.
В тексте думпа написано, что программа прерывается оттого, что insert пытается вставить в таблицу строчки, которые в ней уже есть. Т.е. после исполнения delete , несмотря на то, что данных в таблице уже нет, САП реагирует так, как будто они еще есть, и не допускает исполнения insert .

Вопрос: как исправить ошибку?

Спасибо за ответы.

Проверьте табличку gt_table до insert. Скорее всего дублирующие записи в ней.

ЗЫ А код вроде прально написан. После первого commit табличка должна очиститься, после второго - заполниться.

ЗЗЫ Да и таблички gt_tab и gt_table должны быть одной структуры.

Нет, в gt_table нет дублей. В ключевых полях есть поле Текущий номер, который перед записью обновляется, специально, чтобы избежать одинаковых записей.

Если между delete и insert поставить break-point, или при выполнении программы в debugging-режиме, дампа не происходит никогда. Он происходит не всегда, чаще при больших размерах стираемой и записываемой таблиц, в продуктивной системе чаще, чем у меня в разработке (продуктивная система быстрее). Все это наводит на мысль, что процесс стирания продолжается после commit work, или где-то, помимо ДБ таблицы, записи числятся еще не стертыми, и эта инстанция не дает совершиться insert.

Поэкспериментируйте. Сделайте в серединке вызов DB_COMMIT, либо попробуйте использовать UPDATE TASK.

Вот в том-то и дело, что при большом объёме Вы и не замечаете дубликатов.


А commit work между delete и insert, кстати, вовсе не нужен.

Точно! Не нужен... Это все футбол виноват

Если строчки просто целиком задваиваются (или если есть 100% уверенность, что они не задваиваются ), то можно сделать быструю заплатку:

пока не разобрались в чём дело.

Если же строки с разными данными имеют один ключ, то уже необходимо лечить причину, а не симптомы.

В серединке чего? Извините, не понял.

В записываемой таблице не может быть дубликатов. Одно ключевое поле представляет собой Порядковый номер. Перед записью таблица сортируется и нумерируется заново, так что порядковый номер не повторяется. А вот в стираемой и записываемой таблице вполне могут быть одинаковые записи.

Хм, может и правда commit work убрать? Спасибо за идею, завтра попробую.

Строки с разными, и даже с одинаковыми данными всегда имеют разный ключ.

А если вместо insert modify попробовать? Попробую завтра, о результатах напишу.