Open SQL вычисляемые поля.

lk

8051core написал(а):

И еще небольшой совет, не надо при решении стандартных задач без особой необходимости использовать Native SQL.
Вас потом ваши же коллеги будут тихо ненавидеть за такие костыли в программах.

Я в Native погружаюсь только первый месяц, поэтому не пойму :"В чем подвох???"
ну напишу я часть кода на OPEN и остальное на Native зато все компактно и локанично.

8051core написал(а):

ABAP в принципе нет тот язык где будет все красиво и лаконично. Это Вы консерваторией ошиблись.

Выбирать не пиходится..

какую лопату дали в руки той и копаем!

lk

8051core написал(а):

И еще небольшой совет, не надо при решении стандартных задач без особой необходимости использовать Native SQL.
Вас потом ваши же коллеги будут тихо ненавидеть за такие костыли в программах.

Я в Native погружаюсь только первый месяц, поэтому не пойму :"В чем подвох???"
ну напишу я часть кода на OPEN и остальное на Native зато все компактно и локанично.

8051core написал(а):

ABAP в принципе нет тот язык где будет все красиво и лаконично. Это Вы консерваторией ошиблись.

Выбирать не пиходится..

какую лопату дали в руки той и копаем!

lk

8051core написал(а):

Зачем соединять эти таблицы в рамках одного запроса?
Выберите сначала нужные ключи из ANLA, потом дополните их необходимой информацией и уже делайте запрос к CDHDR

Это действительно самый простой вариант, в рамках одной задачи для налоговиков я так и сделала.

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

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

Parazit

Ваше желание написать красивый SQL-код похвально, это то, чего не хватает многим разработчикам. Однако лучше придерживаться Open SQL, т.к. всегда есть вероятность миграции системы на версию с другой СУБД. Тогда Вас проклянут не только разработчики, но и всё руководство! К тому же есть проблемы с криво спроектированной базой данных, например, связи по составным или частичным ключам, как например, Ваш случай с ANLA и CDHDR. Даже если Native SQL конкретной СУБД позволяет описать такую связь, это всё равно плохое решение. Тут уже не до красоты, ибо SAP-а уже свинью подложила. Поэтому FOR ALL ENTRIES (нелюбимый мной) будет меньшим злом, чем Native.

lk

Parazit ! спасибо за совет. В этой конкрентой ситуации я уже поняла, что смысла никакого нет лезть в Native.
А по поводу миграции на другую версию СУБД я и не подумала.... у нас ORACL 8 уже стоит "сотню" лет. Да и куча приложений вне SAP написано, так что

руководство сто раз подумает прежде чем будет мигрировать.... ( но я то не подумала об этом!!! Спасибо, слудующий раз буду иметь ввиду и эту проблему.)... Пойду подумаю, что можно сдалать... если ничего не придумаю - буду писать топорно.

Удав

Тут Oracle 12-ю версию выпустил. С технологией In-Memory

Paul_80

lk написал(а):

Это решение красивее:

Code:

select anln1 txt50 as zz_field+0(50)
             txa50 as zz_field+50(50)
into corresponding fields of table vib_ok
from anla
 WHERE anla~ANLN1 = '120000000205'.

Проблема в том, что после селекта структура поля zz_field для записей таблицы (если поля txt50 и txa50 занимают не все 50 символов) будет содержать пробелы между выбранными txt50,txa50. Причем, пробелов будет ровно столько, сколько длины txt50 не хватает до 50 символов.

Это что-то типа CONCATENATE .... RESPECTING BLANKS.
И искать/анализировать txa50, начиная c 51-го символа zz_field, поверьте, совершенно неизящно

Правила форума

Open SQL вычисляемые поля.

Кто сейчас на конференции