Добрый день.
Такая проблема в некоторых программах начались проблема выполнения Select-ов, например, такой:
select single name1 from lfa1 into dynp_prad-orgn where lifnr = dynp_znpr-org.

Помогает копирование программы в новую программу, и все работает.

Но хотелось бы понять, что происходит?
Может быть кто-то сталкивался с подобным?

Такое ощущение, что проблема в генерации каких-то процедур, которые отвечают за выборку данных из БД.

База данных на MS SQL.
Версия SAP у нас старая 6.40

Добрый день!
В чем именно проблема выполнения? Медленно работает? Выполните трассировку st05 и проведите анализ совместно с базисом. Так же стоит провести полный анализ всей программы в тр-циях se30\sat\st12, а не только проблемного селекта, т.к. возможно просто вся программа неудачно спроектирована.

Проблема в том, что select - не возвращает данные, хотя они есть. Выдает sy-subrc = 4. Хотя данные есть. И если программу скопировать в новую, тогда все работает.
А вот в этой программе не работает.

Все равно мало данных. Стоит все-таки снять трассировку проблемы в st05: там можно будет увидеть какие именно значения переменных подставноки ушли на уровень БД, ну и сделать какие-то выводы на основании этого.

Чисто из спортивного интереса задачка.
Т.е. SELECT ничего не возвращает из программы с определённым именем.
Предлагаю цепочку действий:

• проверить тип переменной, в которой сидит значение WHERE, совпадает ли с типом поля в таблице (для WHERE)
• сравнить кодировку: UTF, WINDOWS-1251 и т.д. в программе, которая не хочет делать SELECT с кодировкой копии, которая работает.
• посмотреть в значении поля WHERE в таблице есть ли лидирующие пробелы или пробелы в конце.
• значение в поле WHERE содержит ли кирилицу и соотнести с кодировкой в которой создана программа.
• значение в поле WHERE заполнено литералом или из заполняется из кода ранее.

Предположения проблемы таковы: кодировка создания программы и значение в кирилице в значении WHERE.
Я бы для чистоты эксперимента сделал и так: закомментарил весь код кроме SELECT, а WHERE заполнил литералом. Сработает "капризная" программа или нет?

Добрый день.
Проблема в следующем:
Есть некая таблица: ZMARA, а ней поля:
MANDT MANDT CLNT 3 0 Мандант
KEY2 ZTSD_KEY1 INT4 10 0 1-й ключ таблицы
MATNR MATNR CHAR 18 0 Номер материала
MATNR_ALT MATNR CHAR 18 0 Номер материала

Удалили поле KEY2. Сделали ключевыми два других MATNR и MATNR_ALT. Адаптировали таблицу в se14.

таблица активировалась. А вот программа, с которой эта таблица работала - тоже исправили, она активировалась, но при выполнении получаем дамп.
Database error text........: "[207] Invalid column name 'KEY2'."
Internal call code.........: "[RSQL/178/ZMARA_ALT ]"

То есть, система где-то помнит, что это поле есть, и требует его.

Если таблицу вернуть обратно - тогда все начинает работать.

Такое ощущение, что есть некая система меду базой и ABAP.
Типа проблема со словарем данных ?

Кто-то сталкивался с чем-то похожим?

Добрый вечер.

RSQL (или Remote SQL) — это часть архитектуры SAP, которая отвечает за взаимодействие между ABAP-программами и базами данных. Она использует метаданные для выполнения SQL-запросов. Чтобы обновить информацию о структуре данных в RSQL:
Перезагрузка кэша: В некоторых случаях может потребоваться перезагрузка кэша метаданных. Это можно сделать через транзакции, такие как SE11 (Dictionary) и SE14 (Database Utility), где можно выполнить действия по обновлению или пересозданию объектов.

в SE11 и SE14 - таблицы как раз изменяем.

А вот можно как-то эту систему проверить? или обновить кэш RSQL?

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

Забавная история.
У таблицы ZMARA включена буферизация?
Если включена, то попробовать отключить, и переактивировать. Вдруг в этом дело?
В такой неясной ситуации я бы попробовал сделать следдующее

• Восстановил ключевое поле KEY2 в исходной таблице ZMARA;
• Создал в словаре копию таблицы, например с именем ZMARA1 без поля KEY2;
• Если для ZMARA с полем KEY2 SELECT работает, то перенёс бы данные из ZMARA в ZMARA1;

Дальше по обстановке. По идее SELECT для ZMARA1 должен работать. Буфера в словаре к ней ещё нет.
Можно старый код переключить на новую таблицу. Если кода, который обращается к ZMARA очень много, то можно перенос в продуктив сделать в несколько этапов в стиле "очумелые ручки":

1. ZMARA копипуем в ZMARA1 (которая без KEY2);
2. Удаляем ZMARA;
3. создаём сновая ZMARA но уже без KEY2;
4. ZMARA1 копипуем в обновлённую ZMARA.

Тут уж на вкус и цвет все фломастеры разные.
Либо код переключать на ZMARA1 либо копировать, удалять таблицу.

буферизация не включена.
Копирование в новую прогу или в новую таблицу помогает.
Но хотелось бы понять что с этой. Как эту полечить?
с одной то таблицей понятно - что можно скопировать, а если их будет много...

На этом мои АБАП-ские познания иссякли. Возможно действительно стоит обратиться в базис или к админу базы данных.
Если у Вас старая система, то под ней наверное ORACLE. Поспрашивать спецов по БД.

Меня несколько удивляет, как Вам удалось удалить ключевое поле и активровать/адаптировать таблицу.
Посмотрите вниматеольнее, мож она у Вас частично активаированна?
Конечно, если поле KEY2 содержало одинаковое значение во всей таблице (например KEY1 = 1), то фокус с удалением ключевого поля может быть успешным. Если поле было не одинаковым, то это только счастлиый случай.