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

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


Здесь всё просто: слева - всегда поле таблицы, как и в стандартном SELECT, после знака равенства/неравенства - константа в кавычках, переменная в амперсандах, или просто поле ключа без какого-либо обромления.
Но об этом надо просто знать, да.


Возможно я Вас неправильно понял, но вы предлагаете тестировать инструмент, который уже работает? Если что-то работает, то зачем это тестировать?


ТЗ нет, как и описание разработки. Но последнее планируется как только допишется весь функционал.


И здесь мы снова возвращаемся к теме топика В топике я и просил совета как узнать структуру переменной в исходном тексте.
А по поводу тестирования - здесь всё просто: тестируется софт функционально, если он не работает так как надо, то разработчику всё равно придётся лезть в код и править ошибку.
Если программист неправильно написал стандартный SQL запрос, то программа же тоже не будет правильно работать? С моим инструментом то же самое.


Агрегирующие функции не используют SAP BUFFERING, посему их не будет в этой тулзе.
Псевдонимы (AS) есть в TODO листе.
А вот выборки в ту же таблу, что и в FOR ALL ENTRIES, к сожалению, нет и не будет. Как я уже и говорил, для ОГРОМНЫХ массивов данных с критической скоростью работы моя тулза не очень подходит.


Что Вы имеете ввиду под этим?
Если что-то типа этого, то так можно делать:



Спасибо! Довожу до ума уже целый год и как всегда есть к чему стремиться дальше

Самое интересное - реализовать получение данных из смежных буферных таблиц (это когда в ct_buf передаются совершенно разные таблицы, чтобы данные повторно не брались из БД, если указана какая-то другая буферная таблица). Этакая распределённая система буферных таблиц получается.
Ещё нет поддержки AS и IN.

OFFTOP:
Хотелось бы поделиться способом делать пометки TODO прямо в коде.
Можно просто написать несуществующую прагму, которая будет отображаться в предупреждениях при проверке синтаксиса.

Например, попробуйте ввести такую прагму в исходный текст и проверить синтаксис:

По двойному щелчку даже к строке кода переходит

"Знать" и "на ладони" - разные понятия. На ладони: я опечатался в имени поля, а мне сразу синтаксис сказал "мужик, ты - не прав!". А знать, это: я должен вот тут писать вот так. И сам должен проверить, что написал правильно без подсказчиков. Оно разработчику вот надо?

Так это ж Вы предлагаете тестировать правильность передачи в ваш инструмент параметров! Т.е. по сути - функ.тестирование вашего инструмента с каждым набором моих(как рзаработчика) параметров.


В общем случае - никак. Почему? Потому что: переменная может быть определена на таком уровне вложенности, что ее определение можно будет получить только в рантайме. Это получается как за счет возможности передачи переменных generic типов как параметров, передачи как параметров результатов вызова функ.методов, так и за счет гибкой возможности определения самих переменных(например через макросы, в самых извращенных случаях или с расширением станд.типов через энхансы). Т.е. в общем случае нужен не просто синтакс.анализатор, а еще и рантаймовый анализатор последовательности вызовов.
Нормальный подход в таких случаях - проверка входных параметров в рантайме в самом методе. Но тогда - перечитываем дискуссию с начала: толку в инструменте не много, т.к. того самого жаждуемого вами статанализа не будет

Если прогер напишет статический запрос неправильно, то уже по обычной проверке программы, синт.анализ выдаст ошибку. Программа не то что работать - генерироваться не будет. И не будет так нежелаемых Вами дампов. Это работает в подавляющем большинстве случаев.

А это не относится к теме больших объемов данных. Это частая практика: собрали фильтр для FAE и, чтобы не париться, храним его в той же внутр.табле строго до момента выборки.

Мне ближе подход сапа: создание отдельных функ.модулей\методов для буферизованного чтения.

Зря. Очень мощный инструмент, если правильно его использовать
Но не во всех случаях, как и ваша разработка
Как эксперимент она полезна, но для массового использования не подойдет по причинам, описанным Кодером и мной.
В процессе написания вы наверняка многое узнали о реализации Open SQL. Это поможет в будущем грамотно писать программы на ABAP.

Каждый нормальный программист реализовывал какой-нибудь свой мега-проект.
Я например в свое время написал программу универсального пакетного ввода для бух.документов, не зная о стандартном FI posting interface, который делал то же самое
И стал после этого намного лучше разбираться в отладке и стандартных программах SAP.

Конечно не надо. Поэтому я создал эту тему.
А без знаний всё равно ничего не получится сделать, даже при использовании OPEN SQL: если не знаешь синтаксис, то ничего у тебя не получится.
В разработке всё равно приходится узнавать интерфейсы используемых инструментов.


Я предлагаю тестировать в автоматическом режиме. Типа проверки синтаксиса по CTRL+F2, только проверка будет запускаться тестирующими классами по CTRL+SHIFT+F10.


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


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


Да, здесь я с Вами и не спорю. Но при этом можно забыть, например, проверить на заполненность таблицы FOR ALL ENTRIES или написать кучу промежуточного кода, или делать ненужные выборки, что перегрузит код ненужными деталями и нагрузит БД, когда этого можно избежать.


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


Этот подход не так гибок и хорош, как хотелось бы:

1. На каждую таблицу/параметр фильтрации приходится делать отдельный модуль (писать на него ТЗ, писать покрывающие код тесты, функционально тестировать, делать описание разработки, поддерживать... ).
2. Другие программисты не знают имена этих модулей и пишут одно и то же в разных частях системы или тратят своё время на поиск/разбор модуля, который им нужен. Но проще конечно написать заново и плодить сущности в системе
3. Обычно сап пишет модули для буферизованного чтения только для одного кортежа по первичному ключу.
   Мой метод позволяет читать из БД несколько кортежей сразу пачкой только один раз и по любому ключу, а затем сможет брать данные из буферной таблицы из разных разработок, которые совершенно ничего не знают друг о друге.

Т.е. программисту можно просто использовать инструмент и сосредоточится на реализации задачи, а не искать модули, использующие буферизацию (которых может и не быть), не тратить время на изучение/создание/тестирование/поддержку этих модулей.


Если бы нам не приходилось писать что-то новое, то наша работа была бы слишком скучна и неинтересна
А так, конечно, жаль, что всего знать невозможно или чего-то попросту нет и приходится извращаться и делать свои велосипеды

если ошибок нет, можно сделать insert report .. keeping directory entry и на этом остановиться

динамическая типизация (rtti) - путь в никуда (в.и. ленин)

Так синтаксических ошибок и так нет. Могут быть ошибки неправильно переданного параметра.


Я тоже люблю статику. Но так же не люблю делать лишнюю ненужную и скучную работу, поэтому здесь и используется динамика

Ой что я пропустил.

UKY, не взлетит. За такое и побить могут

По существу. Плох тот разработчик, который ни разу не попытался дать свой ответ на The Ultimate Question of Life, the Universe, and Everything. С практической точки зрения, занятие сугубо бесполезное. Для саморазвития специалиста же - крайне полезное.

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

И эти люди не любят SAP Query...