В какой таблице храниться связь название признака и внутренний код? Спасибо.

поиск по *признак* дал 237 таблиц, попробуйте добавить чуть больше информации к своему вопросу

Есть таблица AUSP c полями Objek, ATINN,..где ATINN - Внутренний код признака. Но у каждого признака(А их можно посмотреть с помощью транзакции ct04) есть имя. Я подозреваю что эта связка храниться в какой то таблице. Например внутренний код класса и название класса храниться в KLAH(Что легко посмотреть по проверочной таблице к полю CLINT).

Смотри таблицы CABN и CABNT

опередил, пока меня на работе отвлекли



Витек, вся эта информация по F1 - технические параметры на названии доступна.

Ох, нет на вас Сергея Королева.
Он бы объяснил, почему не надо напрямую читать из таблиц, когда существует множество готовых ФМ.

А никто читать и не собирался, хотели лишь узнать "В какой таблице храниться связь название признака и внутренний код?", ведь "эта связка храниться в какой то таблице"

А я б послушал уважаемого гуру.

Пока могу предложить только такие аргументы:
1) при изменении структуры таблиц запросы полетят.
2) Есть предположение что тексты ФМ-ов оптимизированны по производительности.
3) Логику САПовских таблиц досконально знает только сам САП.

и где критерий выбора метода?
например выбор из AUSP быстрее чем например CLFM_SELECT_AUSP или того же BAPI_OBJCL_GETDETAIL.

Тут, как всегда, есть свои плюсы и минусы.

1) Изменить могут и ф.м., тем более, что документации, например, на CLFM_SELECT_AUSP нет. Только у BAPI-функций гарантированно будет сохранён и интерфейс, и назначение ф.м. в целом.

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

2) Саповские ф.м. по большей части ориентированы на универсальность, а не на производительность. Свой селект под конкретную задачу, как правило, всегда быстрее.

3) Опять же, логику САПовских ф.м. тоже знает только САП, поскольку документации нет.

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

См. http://www.sapboard.ru/forum/viewtopic.php?t=14953

А если вызов BAPI_OBJCL_GETDETAIL вынести в отделную программу, и каждый раз вызывать эту программу, разве тогда память не будет освобождаться?

У меня была анологичная ситуация, правда в цикле вызывался ФМ CUCB_GET_CONFIGURATION. В результате циклического вызова памяти съедалось очень много, но вынеся вызов ФМ в отдельную программу, проблема была решена. Да и еще, эта программа, в которой был вызов CUCB_GET_CONFIGURATION, также вызывалась не для одного значения, а для определенной группы значений.

Кстати, а если сапу ноту выставить, интересно пофиксят? ИМХО некоторые проблемы должны решаться в сапе, а не хаками вокруг ...

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

Конечно текушую проблему решить надо, но можно выставить ноту и когда поправят - поправить у себя.