Блог

Я должен объединить две табличные ACDOCA и BKPF. Я написал для этого следующий код.

 SELECT  a~rbukrs,
        a~racct,
        a~bldat,
        a~blart,
        a~kunnr,
        a~belnr,
        a~sgtxt,
        b~xblnr,
        a~budat,
        a~hsl,
        a~prctr
INTO TABLE @it_final
FROM acdoca AS a
LEFT OUTER JOIN bkpf AS b
  ON a~rbukrs = b~bukrs
 AND a~gjahr = b~gjahr
WHERE a~rbukrs IN @s_bukrs
  AND a~Kunnr IN @s_kunnr
  AND a~Budat IN @s_budat
  AND a~Belnr IN @s_belnr
  AND a~rldnr IN @s_rldnr
  AND a~blart = 'DR' OR a~blart = 'ZK' OR a~blart = 'UE'.
 

Столкнулись со следующими ошибками:—-
Ошибка времени выполнения: DBSQL_SQL_INTERNAL_DB_ERROR

Ошибка SQL «Код SQL: 2048» произошла при доступе к таблице «ACDOCA».

Короткий текст: в классе «CX_SY_OPEN_SQL_DB» произошло исключение

Как мне решить эту проблему? пожалуйста, помогите.

Несколько вещей:

• Выбор непосредственно из таблиц базы данных подвержен ошибкам (например, вы забудете ключи при объединении), и вам приходится иметь дело с этими ужасными немецкими сокращениями (например, Belegnummer -> belnr). С некоторых пор сверху есть представления CDS, например, I_JournalEntryItem с ассоциациями и правильными английскими именами для этих полей, если вы можете их использовать, я бы это сделал (также они выпущены на C1).
• Как уже указывал xQbert, запрос, вероятно, работает не так, как предполагалось, и имеет предопределение над ИЛИ, и поэтому ваш запрос в основном возвращает все из ACDOCA, умноженное на все из BKPF, что, вероятно, приводит к опубликованной вами ошибке базы данных
• С запросами диапазона вы все равно можете получить много результатов (например, миллиарды записей, в зависимости от размера вашей компании), вам следует либо ограничить запрос UP TO , реализовать некоторую разбивку на страницы, либо COUNT(*) сначала и показать ошибку пользователю, если набор результатов слишком велик.

Я бы написал это так:

 TYPES:
 BEGIN OF t_filters,
  company_codes TYPE RANGE OF bukrs,
  customers     TYPE RANGE OF kunnr,
  document_dates TYPE RANGE OF budat,
  accounting_documents TYPE RANGE OF fis_belnr,
  ledgers TYPE RANGE OF rldnr,
 END OF t_filters.

DATA(filters) = VALUE t_filters(
  " filter here
).

SELECT FROM I_JournalEntryItem
  FIELDS
    CompanyCode,
    GLAccount,
    DocumentDate,
    AccountingDocumentType,
    Customer,
    AccountingDocument,
    DocumentItemText,
    _JournalEntry-DocumentReferenceID,
    PostingDate,
    AmountInCompanyCodeCurrency,
    ProfitCenter
  WHERE
    CompanyCode            IN @filters-company_codes AND
    Customer               IN @filters-customers AND
    DocumentDate           IN @filters-document_dates AND
    AccountingDocument     IN @filters-accounting_documents AND
    Ledger                 IN @filters-ledgers AND
    AccountingDocumentType IN ( 'DR', 'ZK', 'UE' )
  INTO TABLE @DATA(sales_orders)
  UP TO 100 ROWS.
 

(В качестве бонуса вы получите надлежащие проверки авторизации DCL)

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

   AND a~blart = 'DR' OR a~blart = 'ZK' OR a~blart = 'UE'.
 

Я бы рассмотрел это вместо этого. В противном случае ВСЕ записи blart ZK и UE возвращаются независимо от клиента, года, компании и т. Д…

 SELECT  a~rbukrs,
        a~racct,
        a~bldat,
        a~blart,
        a~kunnr,
        a~belnr,
        a~sgtxt,
        b~xblnr,
        a~budat,
        a~hsl,
        a~prctr
INTO TABLE @it_final
FROM acdoca AS a
LEFT OUTER JOIN bkpf AS b
  ON a~rbukrs = b~bukrs
 AND a~gjahr = b~gjahr
WHERE a~rbukrs IN @s_bukrs
  AND a~Kunnr IN @s_kunnr
  AND a~Budat IN @s_budat
  AND a~Belnr IN @s_belnr
  AND a~rldnr IN @s_rldnr
  AND a~blart IN ('DR','ZK','UE').
 

Однако, если вы действительно хотели вернуть все записи blart ZK, UE и только те, которые ar DR и в определенных параметрах … вы просто запрашиваете слишком много данных из системы и должны «ОГРАНИЧИТЬ» свой результирующий набор и каким-то образом сообщить пользователю, что возвращается только ограниченный набориз-за объема данных

Я бы также убедился, что вашего соединения с ключами достаточно. Финансовый год и код компании представляют неполный ключ к BKPF. Я не знаю таблицу данных ACDOCA, поэтому я не уверен, что это правильное соединение, которое может привести к полукартовому значению, способствующему раздуванию данных. Я бы подумал, что в многопользовательской БД вам также может потребоваться присоединиться к mandt … возможно, номер документа и некоторые другие значения… опять же, это выглядит как неполное соединение по ключу…. так что, возможно, там тоже нужно больше.