READ TABLE FROM

swd

Доброго всем дня.
Пишу процедуру поиска данных из одной таблицы в другой таблице. Примерно так:

Code:

LOOP AT lt1 ASSIGNING <fs_t1>.
  READ TABLE lt2 FROM <fs_t1> ASSIGNING <fs_t2>.
  IF sy-subrc = 4.
    " похожей записи нет
  ENDIF.
ENDLOOP.

Таблицы lt1 и lt2 содержат по одной записи. Структуры таблиц одинаковые. Записи по значениям полей НЕ СОВПАДАЮТ.
READ TABLE возвращает 0, т.е. строка найдена. При просмотре в отладчике значений <fs_t1> и <fs_t2> они отличаются.
Почему же так происходит?

bossjohn

Если вы хотите найти в lt2 строку идентичную lt1, то неверно пользуетесь опцией FROM.
она предназначена для другого

Цитата:

... [FROM idx1] [TO idx2]

Effect

These additions have the effect that only table rows from row number idx1, or up to row number idx2, are taken into account in the table index used.

swd

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

Если вы хотите найти в lt2 строку идентичную lt1, то неверно пользуетесь опцией FROM.
она предназначена для другого

А как же READ TABLE itab FROM wa ?

bossjohn

swd написал:

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

Если вы хотите найти в lt2 строку идентичную lt1, то неверно пользуетесь опцией FROM.
она предназначена для другого

А как же READ TABLE itab FROM wa ?

Упс, прошу прощения, был не внимателен и написал для LOOP :oops:

LinevskiySV

Заголовок: READ TABLE FROM

swd написал:

Таблицы lt1 и lt2 содержат по одной записи. Структуры таблиц одинаковые. Записи по значениям полей НЕ СОВПАДАЮТ.

По значениям каких полей не совпадают. Запись FROM находит по ключу, если ключ явно не объявлен, то комбинация всех clike полей.

bossjohn

LinevskiySV написал:

Заголовок: READ TABLE FROM

swd написал:

Таблицы lt1 и lt2 содержат по одной записи. Структуры таблиц одинаковые. Записи по значениям полей НЕ СОВПАДАЮТ.

По значениям каких полей не совпадают. Запись FROM находит по ключу, если ключ явно не объявлен, то комбинация всех clike полей.

+1
покажите как объявляли таблицы и что в них содержится

Leha

Code:

REPORT  TEST.
TYPES: begin of t1,
        num type i,
        text(5) type c,
       end of t1.
data: lt1 type SORTED TABLE OF t1 with UNIQUE key num,
      wa1 like line of lt1,
      lt2 type  SORTED TABLE OF t1 with UNIQUE key num,
      wa2 like line of lt2.
wa1-num = 1.
wa1-text = 'text1'.
append wa1 to lt1.
wa2-num = 2.
wa2-text = 'text2'.
append wa2 to lt2.
FIELD-SYMBOLS: <fs_t1> like line of lt1,
               <fs_t2> like line of lt2.
LOOP AT lt1 ASSIGNING <fs_t1>.
  READ TABLE lt2 FROM <fs_t1> ASSIGNING <fs_t2>.
  IF sy-subrc <> 0.
    write: / 'Похожей записи нет'.
  ELSE.
    write: / 'Записи похожи'.
  ENDIF.
ENDLOOP.

Сравнивается ключ...если поставить num в обоих таблицах 1, то на экран выведется 'Записи похожи', если разный ключ, то 'Похожей записи нет'. Хотя остальные поля и отличаются.

swd

Цитата:

По значениям каких полей не совпадают. Запись FROM находит по ключу, если ключ явно не объявлен, то комбинация всех clike полей.

Таблица содержит столбцы:
- дата начала
- дата конца
- сумма без ндс
- сумма ндс
- сумма с ндс
Записи отличаются по суммовым полям, но совпадают по датам.
Все поля не являются ключевыми.

bossjohn

swd написал:

Цитата:

По значениям каких полей не совпадают. Запись FROM находит по ключу, если ключ явно не объявлен, то комбинация всех clike полей.

Таблица содержит столбцы:
- дата начала
- дата конца
- сумма без ндс
- сумма ндс
- сумма с ндс
Записи отличаются по суммовым полям, но совпадают по датам.
Все поля не являются ключевыми.

Вот именно об этом и писал LinevskiySV
суммовое поле в данном случае не clike поле и не влияет на результат.

Пономарев Артем

swd, а у вас всегда будет по одной записи в таблицах? А то код, как бы это помягче, не самый оптимальный с точки зрения производительности

swd

Цитата:

суммовое поле в данном случае не clike поле и не влияет на результат.

В таком случае как его таковым сделать? Структура таблиц формируется мной программно. Далее туда отбираются данные для сравнения из физической таблицы по заданным критериям.

bossjohn

swd написал:

Цитата:

суммовое поле в данном случае не clike поле и не влияет на результат.

В таком случае как его таковым сделать? Структура таблиц формируется мной программно. Далее туда отбираются данные для сравнения из физической таблицы по заданным критериям.

таковым его не сделать, ибо

Цитата:

clike -> Character-type (c, d, n, t, string and character-type flat structures); in non- Unicode programs also x, xstring and any flat structures

может пересмотреть подход к решению задачи ибо

Пономарев Артем написал:

swd, код, как бы это помягче, не самый оптимальный с точки зрения производительности

?

swd

Пономарев Артем написал:

swd, а у вас всегда будет по одной записи в таблицах? А то код, как бы это помягче, не самый оптимальный с точки зрения производительности

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

Пономарев Артем

swd, а вы опишите задачу. Потому как "структура таблиц формируется мной программно" намекает, что не все так просто.

А предложения обычные. HASH/SORTED использовать, как первый шаг. Или BINARY SEARCH.

swd

Пономарев Артем написал:

swd, а вы опишите задачу. Потому как "структура таблиц формируется мной программно" намекает, что не все так просто.
А предложения обычные. HASH/SORTED использовать, как первый шаг. Или BINARY SEARCH.

Есть 2 набора записей, выбираемые из одной таблицы. Список отбираемых полей для разных видов объектов лежит в настроечной таблице. Там же у каждого поля есть признак, ключевое оно или нет (к ключевым полям таблицы словаря отношения не имеет). Задача - сравнить эти 2 набора и сформировать таблицу сравнения в виде:
- значения ключевых полей (ключевых - по данным настроечной таблицы)
- вид изменения (запись добавлена, удалена, изменена).
Если бы надо было сравнивать записи таблицы из словаря, можно было бы воспользоваться методом cl_reca_storable=>get_change_indicator. Но в данном случае список полей берется из таблицы настройки. Поэтому и приходится создавать структуру таблицы программно (с помощью cl_alv_table_create=>create_dynamic_table) и изобретать что-то свое для сравнения... Ну или может есть нечто типовое для таких случаев, а я чего-то не знаю.

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

READ TABLE FROM

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