Станьте участником SAPLAND и получите доступ к самым интересным публикациям SAPPRO
Зарегистрироваться
Добрый день.
Подскажите, пожалуйста, есть ли запись вебинара для просмотра?
Вы пишите: "Для этого открываем SAP HANA Studio".
Вот инструкция где взять
help.sap.com/viewer/a2a49126a5c546a9864aae22c05c3d0e
Но если You are signed in with a P-user ID.
То log in with your S-user ID.
Как получить S-user ID не очень понятно для условно продавца в пятерочке, который решил в домашних условиях сменить род деятельности. Похоже ни как. Вероятно здесь я не прав.
Доброго дня! При создании 16* счетов со значением "*" в налоговой категории мне сделали замечание, что в этих счетах недопустим код налога. Могли бы уточнить так ли это и почему?
Это вы что ли транзакцию SE93 с такой радостью обнаружили? У меня в системе сейчас 151 023 штуки, за вычетом Z-транзакций. А сколько в вашей базе :-)
Уже не требуется, нашел базу всех транзакций SAP. Будет время, попробую выделить среди них, относящиеся к безопасности. При положительном стечении, напишу колонку.
Подскажите пожалуйста, где можно подробнее посмотреть перечень транзакций, относящихся к безопасности SAP?
AIS именно и содержит набор отчетов и транзакций, которые показывают те или иные "дыры" в системе в разрезе информационной безопасности.
Настройка основных данных в Управлении проектами в SAP
16.06.2026Разработка SAPUI5 приложений
23.03.2026Расширенное управление складами: базовая настройка
02.03.2026SAP HANA: Установка и администрирование
15.06.2026
Комментарий от
Виталий Глущенко
| 16 марта 2020, 20:01
На своих экспериментах не увидел выигрыша между mesh структурой и внутренними табличками. Как правило разница в производительности колебалась +/-7%, если повторять такой "join" несколько раз, то разница в производительности скатывается до +/-1-2%.
При этом заполнение, что внутренних структур, что mesh структуры требует одинакового времени.
Разочаровывало (1) отсутствие поддержки Open SQL, поэтому собирать mesh структуру надо ручками и то, что (2) чтение одной и той же записи из mesh структуры, во второй и последующие разы занимает столько же времени сколько и в первый раз. Спрашивается, а зачем тогда мы указываем связи между полями с детализацией до полей (я про ASSOCIATION). На каждую ASSOCIATION в запись в главной таблице можно было добавить либо индекс, либо сразу адрес, который заполнялся бы при первом обращении, а при изменении строки сбрасывался. Overhead по памяти был бы незначительный, а скорость выросла. И последнее из явных разочарований (3), связи между таблицами только через = и and, а если у меня несколько таблиц с датой начала/датой окончания, то ASSOCIATION по такому ключу я уже не соберу, понятно.